Hi Corentin,

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

Since I wrote this part of the paper I'm happy to take responsibility for
"monkey see monkey do." I thought it would be desirable to match
basic_string_view as closely as possible, however, I don't think we have
any partiality to this aspect of the paper.

> It is not useful

I think I'm inclined to agree.

--
> 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.
My apologies for this unclarity. I was trying to satisfy both polls
regarding a path-precedent and a bag of bytes as well as comments from the
LEWGI telecon. I'm not entirely happy with the interface myself.
> But from a standard perspective, I think we ought to assume main() has
been called, and that by definition, main's arguments are in the
environment encoding (or not text).
I think the main thing I was getting confused about regarding the bag of
bytes was whether the bytes should be what the process gets from the OS
natively or whether they should match the char** argv arguments main would
have. If the latter, that would imply code page conversion on windows and
I'm not sure that's desirable.
Cheers,
Jeremy
On Wed, Apr 9, 2025 at 4:10 AM Corentin Jabot <corentinjabot_at_[hidden]>
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)
>
> 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
>>
>