ranges::to's from_range_t tag branch has the wrong constraint
Hewill Kang

Created on 2023-01-06.00:00:00 last changed 10 months ago


Date: 2023-02-02.15:14:57

Proposed resolution:

This wording is relative to N4917.

  1. Modify [range.utility.conv.to] as indicated:

      template<class C, input_range R, class... Args> requires (!view<C>)
        constexpr C to(R&& r, Args&&... args);

    -1- Returns: An object of type C constructed from the elements of r in the following manner:

    1. (1.1) — If convertible_to<range_reference_t<R>, range_value_t<C>> is true:

      1. (1.1.1) — If constructible_from<C, R, Args...> is true:

      2. C(std::forward<R>(r), std::forward<Args>(args)...)
      3. (1.1.2) — Otherwise, if constructible_from<C, const from_range_t&, R, Args...> is true:

      4. C(from_range, std::forward<R>(r), std::forward<Args>(args)...)
Date: 2023-02-15.00:00:00

[ 2023-02-02; Reflector poll ]

Set priority to 4 after reflector poll. Several votes for "Tentatively Ready", but also two objections, preferring NAD. The proposed change would appear to bless unconventional uses of from_range, and we don't want to support or encourage that. The current wording is simpler, and works for the intended cases.

Date: 2023-01-06.00:00:00

In bullet (1.1.2), ranges::to checks whether the container type C models constructible_from<from_range_t, ...> and constructs it via C(from_range, ...).

Since from_range is a constexpr variable here, it would be more accurate to constrain C to be constructible from a const lvalue tag rather than an rvalue tag.

Date User Action Args
2023-02-02 15:14:57adminsetmessages: + msg13254
2023-01-06 14:50:57adminsetmessages: + msg13177
2023-01-06 00:00:00admincreate