This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.
viewable_range
is not quite rightSection: 25.4.5 [range.refinements] Status: New Submitter: Hewill Kang Opened: 2023-02-27 Last modified: 2023-03-22
Priority: 4
View all other issues in [range.refinements].
View all issues with New status.
Discussion:
The requirements of viewable_range
for view
type is view<remove_cvref_t<T>> &&
constructible_from<remove_cvref_t<T>, T>
, that is, when the decayed type of T
models view
,
it must be constructible from T
.
This part of the constraint corresponds to first bullet of views::all
(25.7.6.1 [range.all.general]),
which returns decay-copy(E)
if the decayed type of E
models view
.
However, decay-copy(E)
constraints convertible_to<T, decay_t<T>>
which is a
stronger requirement than constructible_from
, which is reflected in its rejection of types with explicit
copy constructors.
This inconsistency is such that the following causes the range adapter to produce a hard error when invoked (online example):
#include <ranges>
struct View : std::ranges::view_base
{
View();
explicit View(const View&); // explicit copy constructor
View& operator=(const View&);
View(View&&);
int* begin();
int* end();
};
int main()
{
View v;
auto r = std::views::take(v, 5); // hard error
}
[2023-03-22; Reflector poll]
Set priority to 4 after reflector poll. "About as contrived as it gets." "Add generic front matter telling users the library doesn't support types with explicit copy constructors."
Proposed resolution:
This wording is relative to N4928.
Modify 25.4.5 [range.refinements] as indicated:
template<class T> concept viewable_range = range<T> && ((view<remove_cvref_t<T>> && convertible_to<T, remove_cvref_t<T>>constructible_from<remove_cvref_t<T>, T>) || (!view<remove_cvref_t<T>> && (is_lvalue_reference_v<T> || (movable<remove_reference_t<T>> && !is-initializer-list<T>))));