On Wed, Apr 9, 2025 at 8:18 PM Tom Honermann <tom@honermann.net> 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 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 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.

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