Just my 2 cents.
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)
--
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
SG16 will hold a meeting today,
Wednesday, April 9th, at 19:30 UTC (timezone conversion).
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.
The agenda follows.
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.