I would like to participate in this meeting.
But if that's not possible I would like to share my concerns here.

I agree with the sentiment on char_traits, I came to the same conclusion (while doing separate work) that it's inclusion has some fatal flaws that do more harm than good, and that if we can we should avoid it.

However, I don't see zstring_view as a requirement for std::arguments, even though the OS may present this (as an implementation detail) as null terminated string we don't actually need to provide that guarantee to make it coherent.
To add to that, it is my genuine belief that null terminated strings as a practice has been responsible for the vast majority of security vulnerabilities and memory safety problems as well as other miscellaneous inefficiencies. It's one of the key causes that make languages like C and C++ to have such a bad reputation.
If I was given the opportunity to go back in time and eliminate something from the history of computing, this would have been it.
The reasons for that is a bit too large to explain on this email.
But suffice to say that I don't support the use of it in principle. And that any interface going forward would be better off not having the assumption of null terminated.

Just my 2 cents.



________________________________
From: SG16 <sg16-bounces_at_[hidden]> on behalf of Corentin Jabot via SG16 <sg16_at_[hidden]>
Sent: Wednesday, April 9, 2025 10:58:54 AM
To: sg16_at_[hidden]cpp.org <sg16_at_[hidden]>
Cc: Corentin Jabot <corentinjabot_at_[hidden]>; Jeremy Rifkin <jeremy_at_[hidden]>; Peter Bindels <dascandy_at_[hidden]>; Hana Dusíková <hanicka_at_[hidden]>; Tom Honermann <tom_at_[hidden]>
Subject: Re: [isocpp-sg16] Agenda for the 2025-04-09 SG16 meeting

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]<mailto: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]rg<mailto:SG16_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg16