On 4/9/25 8:28 AM, Tiago Freire wrote:
> I would like to participate in this meeting.
> But if that's not possible I would like to share my concerns here.

You may certainly participate. I'll send meeting details privately.

It is always useful to share concerns on the mailing list ahead of the
meeting, so thank you for doing so.

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

There is, as usual, a tradeoff; the ability to efficiently use the many
existing interfaces that consume null-terminated strings. I think there
is general agreement that new interfaces should not be specified with a
requirement to consume null-terminated strings.

Tom.

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