This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++20 status.

### 3179. `subrange` should always model `Range`

Section: 26.5.4.2 [range.subrange.ctor] Status: C++20 Submitter: Casey Carter Opened: 2018-12-21 Last modified: 2021-02-25

Priority: 0

View all issues with C++20 status.

Discussion:

The constructors of `subrange` place no requirements on the iterator and sentinel values from which a `subrange` is constructed. They allow constructions like `subrange{myvec.end(), myvec.begin()}` in which the resulting `subrange` isn't in the domain of the `Range` concept which requires that "`[ranges::begin(r), ranges::end(r))` denotes a range" ([range.range]/3.1). We should forbid the construction of abominable values like this to enforce the useful semantic that values of `subrange` are always in the domain of `Range`.

(From ericniebler/stl2#597.)

[2019-01-20 Reflector prioritization]

Set Priority to 0 and status to Tentatively Ready

Proposed resolution:

This wording is relative to N4791.

1. Change 26.5.4.2 [range.subrange.ctor] as indicated:

   > >     constexpr subrange(I i, S s) requires (!StoreSize);

   > -?- Expects: `[i, s)` is a valid range.

   > -1- Effects: Initializes `begin_` with `i` and `end_` with `s`.

   > >     constexpr subrange(I i, S s, iter_difference_t<I> n)
   > >       requires (K == subrange_kind::sized);

   > -2- Expects: `[i, s)` is a valid range, and `n == ranges::distance(i, s)`.