Title
basic_string_view should allow explicit conversion when only traits vary
Status
new
Section
[string.view.cons]
Submitter
Casey Carter

Created on 2023-01-10.00:00:00 last changed 2 weeks ago

Messages

Date: 2023-01-15.10:43:21

Proposed resolution:

This wording is relative to N4917.

  1. Modify [string.view.cons] as indicated:

    template<class R>
      constexpr explicit basic_string_view(R&& r);
    

    -11- Let d be an lvalue of type remove_cvref_t<R>.

    -12- Constraints:

    1. (12.1) — remove_cvref_t<R> is not the same type as basic_string_view,

    2. (12.2) — R models ranges::contiguous_range and ranges::sized_range,

    3. (12.3) — is_same_v<ranges::range_value_t<R>, charT> is true,

    4. (12.4) — is_convertible_v<R, const charT*> is false, and

    5. (12.5) — d.operator ::std::basic_string_view<charT, traits>() is not a valid expression, and.

    6. (12.6) — if the qualified-id remove_reference_t<R>::traits_type is valid and denotes a type, is_same_v<remove_reference_t<R>::traits_type, traits> is true.

Date: 2023-01-10.00:00:00

basic_string_view has a constructor that converts appropriate contiguous ranges to basic_string_view. This constructor accepts an argument by forwarding reference (R&&), and has several constraints including that specified in [string.view.cons]/12.6:

if the qualified-id remove_reference_t<R>::traits_type is valid and denotes a type,  is_same_v<remove_reference_t<R>::traits_type, traits> is true.

This constraint prevents conversions from basic_string_view<C, T1> and basic_string<C, T1, A>  to basic_string_view<C, T2>. Preventing such seemingly semantic-affecting conversions from happening implicitly was a good idea, but since the constructor was changed to be explicit it no longer seems necessary to forbid these conversions. If a user wants to convert a basic_string_view<C, T2> to  basic_string_view<C, T1> with static_cast<basic_string_view<C, T1>>(meow) instead of by writing out basic_string_view<C, T1>{meow.data(), meow.size()} that seems fine to me. Indeed, if we think conversions like this are so terribly dangerous we probably shouldn't be performing them ourselves in [format.arg]/9 and [format.arg]/10.

History
Date User Action Args
2023-01-15 10:43:21adminsetmessages: + msg13210
2023-01-10 00:00:00admincreate