ranges::enable_safe_range
should not be constrainedSection: 25.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
).
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.
Modify 25.2 [ranges.syn] as indicated:
[Drafting note: The definition in 25.4.2 [range.range] p7 is already unconstrained, which contradicts the synopsis.]
[…] // 25.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; […]