Proposed resolution:

This wording is relative to N4981.

1. Modify [range.concat.overview] as indicated:

   -2- The name views::concat denotes a customization point object ([customization.point.object]). Given a pack of subexpressions Es..., the expression views::concat(Es...) is expression-equivalent to

   1. (2.1) — views::all(Es...) if Es is a pack with only one element whose type models input_range,

   2. (2.2) — otherwise, concat_view(Es...).

[ St. Louis 2024-06-29; Status changed: Voting → WP. ]

[ 2024-05-08; Reflector poll ]

Set status to Tentatively Ready after seven votes in favour during reflector poll.

Currently, views::concat will return views::all(r) when it takes only one argument, which only requires that the type of r models viewable_range which includes output_range:

std::vector<int> v;
auto r = std::views::counted(std::back_inserter(v), 3);
auto c = std::views::concat(r); // well-formed

Since concat_view requires all ranges to be input_range, this seems inconsistent. We should reject the above just like views::zip_transform still requires F to be move_constructible in the case of an empty pack.