On 4/9/25 2:26 PM, Peter Bindels wrote:
>
>
> On Wed, Apr 9, 2025 at 8:18 PM Tom Honermann <tom_at_[hidden]> wrote:
>
> On 4/9/25 4:58 AM, Corentin Jabot via SG16 wrote:
>> A few pre-meeting comments.
>>
>> I think the agenda should be swapped: It is _much_ saner to work
>> on std::arguments if we can admit the existence of zstring_view -
>> to the extent I'd consider zstring_view a requirement for
>> std::arguments.
>>
>> On zstring_view: Can anyone provide justification for char_traits
>> beside "monkey see, monkey do"? I would like us to stop
>> perpetuating past misguidances in perpetuity and just not have
>> that trait in the interface of zstring_view.
>> Sure, it's inconsistent, but we are learning. It is not useful,
>> and it's easier to not add it than to remove it (to the extent
>> that not removing it is not likely to be ever possible)
>
> Maybe.
>
> Section 6.1 (zstring_view and string_view relation) of P3655R0
> <https://wg21.link/p3655r0#zstring_view-and-string_view-relation>
> concludes that std::zstring_view can't be implemented in terms of
> std::string_view. I'm not yet convinced that is correct though. I
> agree that slicing is a problem that makes inheritance
> undesirable, but use as a data member with public conversion to a
> const reference could be useful to reduce the occurrence of
> temporaries and their associated lifetime issues.
>
> template<class charT, class traits = char_traits<charT>>
> class basic_zstring_view {
> ...
> using __rep_type = basic_string_view<charT, traits>;
> using __rep_const_ref = const __base_type&;
> __rep_type sv; // exposition only.
> public:
> constexpr operator __rep_const_ref() const {
> return sv;
> }
> };
>
> The problem with implementing it with string_view in any externally
> observable way is that it does not behave like a string_view; it does
> not support some of the operations that string_view does support.
> Specifically, if you use remove_suffix
> <https://en.cppreference.com/w/cpp/string/basic_string_view/remove_suffix>
> on it, it no longer is a zstring_view.
That is the motivation for only exposing it as a const reference above;
calling remove_suffix() would require making a (string_view) copy first.
>
> Of course, the above could just hard code char_traits<charT>.
>
> I tend to agree that char_traits has been a failure. At the same
> time, I think it would be unfortunate if behavioral differences
> were to emerge between string_view and zstring_view due to
> char_traits. My inclination is to retain the symmetry to ensure
> that zstring_view is always substitutable for string_view.
>
> The reason to keep it is to make zstring_view as similar to
> string_view and string as we can. We agree that char_traits are
> useless, but at the same time we want to make sure that a conversion
> from zstring_view to string or string_view will happen unimpeded by
> any char_traits differences that users might try to do anyway.

+1.

Tom.

>
> If we believe that we can get consensus to add the type without
> char_traits, then I'm all for it. But I believe consensus will be
> higher in LEWG with it, and as such it's in there.