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;
       }
    };

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.

Tom.

>
> Besides that, I have no SG16 concern on this paper, so ship it.
> Note that the reflection people currently seem to be keen on shipping
> string_view-based interfaces (which is fine, really, there is no need
> for null termination in reflection-based interface)
>
> --
>
> std::arguments:
>
> I'm still very much opposed to the design from an SG16 perspective
> (even if I hope the paper ultimately makes progress for C++29)
> This is trying to shove ad-hoc conversions between encodings into an
> interface that ought to be a bag of bytes. We should have these
> concerns separated.
> (and we certainly do not want to have support for u8,u16, and u32 in
> the same interface, let alone path)
>
> The previous poll reflects this, and the paper is not explicit about
> the motivation for not following guidance.
> In particular, the paper mentions WMain, but this is non-standard -
> Note that I would not be opposed to something like warguments being
> conditionally available on these platforms - it certainly would be a
> more elegant solution to that problem.
>
> But from a standard perspective, I think we ought to assume main() has
> been called, and that by definition, mains arguments are in the
> environment encoding (or not text).
>
> Cheers
>
>
>
> On Wed, Apr 9, 2025 at 6:06 AM Tom Honermann via SG16
> <sg16_at_[hidden]> wrote:
>
> SG16 will hold a meeting *today*, Wednesday, April 9th, at 19:30
> UTC (timezone conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20250409T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>).
>
> *For those in Europe, please note that daylight savings time has
> begun, so this meeting will begin one hour later relative to the
> last meeting.*
>
> If you need a .ics file to import into your calendar, you can
> download it here
> <https://documents.isocpp.org/remote.php/dav/public-calendars/R7imgS2LJD9xfeWN/94A3D3A0-70B9-4847-935F-9453DB2BB216.ics?export>.
>
> The agenda follows.
>
> * D3474R1: std::arguments
> <https://jeremy-rifkin.github.io/proposals/drafts/cpp/D3474R1.html>.
> * P3655R0: std::zstring_view <https://wg21.link/p3655r0>.
>
> *D3474R1* comes to us courtesy of Jeremy Rifkin and seeks to
> provide a modern interface to access program arguments (also known
> as command line options). The design exposes the program arguments
> as a contiguous sequence of elements of type std::argument via
> std::span. The members of std::argument closely parallel those of
> std::filesystem::path and provide conversion to char, wchar_t,
> char8_t, char16_t, and char32_t representations. An additional
> path() member enables conversion directly to std::filesystem::path
> thereby allowing the implementation to correctly transcode a
> program argument to a correctly encoded file path for the
> platform. Raw access to the program arguments is provided by
> native(), native_string(), and c_str() members. Access to the
> program options is read-only and provided by a std::arguments()
> function. Since memory allocation might be required, allocator
> support is also provided. The primary concern for SG16 is, of
> course, matters of encoding. The encoding of program arguments, at
> least for POSIX platforms, usually corresponds to the encoding
> corresponding to std::text_encoding::environment() (which may
> differ from the current C and C++ locales). We should discuss
> implementation concerns, including any locale related ones. Given
> our collective expertise in how program arguments are provided by
> implementations and used by programmers, we may want to identify a
> list of considerations for LEWG to keep in mind for their design
> review and/or suggest changes that aren't necessarily related to
> core SG16 concerns.
>
> *P3655R0* also has Jeremy's name on it, but accompanied by the
> familiar names of Peter Bindels and Hana Dusíková. It seeks to
> standardize a variant of std::string_view that offers a null
> termination guarantee. This is not the first paper to propose such
> a type; nor the second, nor the third! Given the history of papers
> (see section 3 in the paper) that stalled for one reason or
> another, the motivation for SG16 review is to provide a (hopefully
> strong) recommendation to LEWG (one way or the other) regarding
> the utility of the proposed type from a group of text experts.
>
> Tom.
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>
>