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.

### 3351. `ranges::enable_safe_range` should not be constrained

Section: 26.2 [ranges.syn] Status: C++20 Submitter: Jonathan Wakely Opened: 2019-12-05 Last modified: 2021-02-25

Priority: 0

View other active issues in [ranges.syn].

View all other issues in [ranges.syn].

View all issues with C++20 status.

Discussion:

Currently `ranges::enable_safe_range` is constrained with `ranges::range`, which not only forces the compiler to do unnecessary satisfaction checking when it's used, but also creates a tricky dependency cycle (`ranges::range` depends on `ranges::begin` which depends on `ranges::enable_safe_range` which depends on `ranges::range`).

The only place the variable template is expected to be used is in the `ranges::safe_range` concept, which already checks `range<T>` before using `enable_safe_range<T>` anyway.

The constraint serves no purpose and should be removed.

[2019-12-12 Issue Prioritization]

Status to Tentatively Ready and priority to 0 after eight positive votes on the reflector.

Proposed resolution:

This wording is relative to N4842.

1. Modify 26.2 [ranges.syn] as indicated:

   > [Drafting note: The definition in 26.4.2 [range.range] p7 is already unconstrained, which contradicts the synopsis.]

   >     […]
   >     // 26.4.2 [range.range], ranges
   >     template<class T>
   >     concept range = see below;

   >     template<rangeclass T>
   >     inline constexpr bool enable_safe_range = false;

   >     template<class T>
   >     concept safe_range = see below;
   >     […]