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.

> 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.

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.