Created on 2019-12-05.00:00:00 last changed 45 months ago
Proposed resolution:
This wording is relative to N4842.
Modify [ranges.syn] as indicated:
[Drafting note: The definition in [range.range] p7 is already unconstrained, which contradicts the synopsis.]
[…] // [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; […]
[ 2019-12-12 Issue Prioritization ]
Status to Tentatively Ready and priority to 0 after eight positive votes on the reflector.
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.History | |||
---|---|---|---|
Date | User | Action | Args |
2021-02-25 10:48:01 | admin | set | status: wp -> c++20 |
2020-02-24 16:02:59 | admin | set | status: voting -> wp |
2020-01-17 04:54:50 | admin | set | status: ready -> voting |
2019-12-12 18:26:00 | admin | set | messages: + msg10881 |
2019-12-12 18:26:00 | admin | set | status: new -> ready |
2019-12-07 14:36:06 | admin | set | messages: + msg10867 |
2019-12-05 00:00:00 | admin | create |