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)

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
>