Created on 2020-08-29.00:00:00 last changed 5 months ago
Proposed resolution:
This wording is relative to N4861.
Modify [range.refinements] as indicated:
-5- The viewable_range concept specifies the requirements of a range type that can be converted to a view safely.
template<class T> concept viewable_range = range<T> &&(borrowed_range<T> || view<remove_cvref_t<T>>);((view<remove_cvref_t<T>> && constructible_from<remove_cvref_t<T>, T>) || (!view<remove_cvref_t<T>> && borrowed_range<T>));
[ 2020-09-06; Reflector prioritization ]
Set priority to 2 during reflector discussions.
The viewable_range concept ([range.refinements]) and the views:all range adaptor ([range.all]) are duals: viewable_range is intended to admit exactly types T for which views::all(declval<T>()) is well-formed. (Recall that views::all(meow) is a prvalue whose type models view when it is well-formed.) Before the addition of move-only view types to the design, this relationship was in place (modulo an incredibly pathological case: a volatile value of a view type with volatile-qualified begin and end models viewable_range but is rejected by views::all unless it also has a volatile-qualified copy constructor and copy assignment operator). Adding move-only views to the design punches a bigger hole, however: viewable_range admits lvalues of move-only view types for which views::all is ill-formed because these lvalues cannot be decay-copied.
It behooves us to restore the correspondence between viewable_range and views::all so that instantiations of components constrained with viewable_range (which often appears indirectly as views::all_t<R> in deduction guides) continue to be well-formed when the constraints are satisfied.History | |||
---|---|---|---|
Date | User | Action | Args |
2020-09-13 15:00:23 | admin | set | messages: + msg11482 |
2020-08-29 17:05:04 | admin | set | messages: + msg11467 |
2020-08-29 00:00:00 | admin | create |