Hi Tiago, thanks for the thoughts and 2c.

> If this is not a zero-cost abstraction (which it doesn't appear to
> be), this is going to be dead on arrival.
> I don't want to have to pay a cost for having this feature in the
> language that I don't even use.

It's zero-cost. Past committee discussion indicated a clear desire to
not impose any startup cost and I've treated that as a design requirement.

The intent of the design provided is to not even require backing storage
for an array of std::arguments and allow a lot of implementation
flexibility. Specifically on Windows, it would be possible with this
design to lazily tokenize the command line string while iterating over
the std::arguments.

Regarding whether arguments are present at all, that's what I had in
mind with std::arguments::empty().

Cheers,
Jeremy


On Sep 30 2024, at 7:01 am, Tiago Freire <tmiguelf_at_[hidden]> wrote:

> One of the main problems I see with this is that the features is not
> as universal as you might think.
>
> On Linux you do have an individual number of distinct strings being
> passed in as an array that you can iterate as individual tokens.
> On Windows, this is not the case, what gets passed around is just a
> single string with the contents of the "command line" (and quotes is
> used here, because a n actual terminal may not even need to exist).
> I.e. no individual tokens. Although on windows you can have a main
> with individual tokenized arguments, this is a result of additional
> pre-processing that takes place to service you that.
>
> But this pattern of having a "terminal like application" with
> individual "countable string tokens" being passed around is hardly the
> whole set of total code that can be written in C++.
> Sure, IF they exist these arguments are accessible outside of main,
> and getting access to them is generally not a problem.
> The problem is:
> IF
> and
> HOW
>
> Adding it as a feature that arguments are accessible under the
> specific pattern of "individualized" numerable tokens, will mean that
> there's going to be an extra work that needs to be done on certain
> platforms that natively don't do it this way.
> I already have a solution to deal with this, that is friendly to the
> operating system way of doing things, that doesn't require the
> standard to do anything from me.
> So certainly, I will not be benefitting from this, and I expect that
> the vast majority of developers this is not even relevant enough for
> them to care.
> If this is not a zero-cost abstraction (which it doesn't appear to
> be), this is going to be dead on arrival.
> I don't want to have to pay a cost for having this feature in the
> language that I don't even use.
>
> And I'm not even going into detail regarding the IF this not even existing.
> One of the things that currently upset me about the standard if stuff
> like the existence of a standard cout and cin, which might not exist,
> and more and more user-oriented applications are going into this
> direction, and yet there's no clear interface to test for the
> existence of these streams. It's a bad assumption to just assume that
> they do.
>
> That would be my 2c.
>
> -----Original Message-----
> From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf
> Of Jeremy Rifkin via Std-Proposals
> Sent: Monday, September 30, 2024 2:47 AM
> To: std-proposals_at_[hidden]
> Cc: Jeremy Rifkin <jeremy_at_[hidden]>
> Subject: [std-proposals] A draft for a std::arguments proposal
>
> Hi,
> I'm drafting a proposal to add std::arguments which would provide an
> encoding-friendly and modern interface for accessing program arguments.
> This is a follow-up for half of Izzy Muerte's paper P1275 Desert
> Sessions: Improving hostile environment interactions. A follow-up to
> the other half, std::environment, is being separately worked on.
>
> Draft: https://jeremy-rifkin.github.io/proposals/drafts/cpp/arguments-draft-1.html
> Very rough sketch to get a feel for the interface: https://godbolt.org/z/d7zvKc4xj
>
> The two main places I'm still weighing pros and cons on the design are
> whether the iterators for std::arguments_view should meet the
> requirements of Cpp17RandomAccessIterator, which would require backing
> storage for the `std::argument`s being iterated over, and what the
> behavior should be if the user modifies argv from main. While I think
> it would be desirable to not have changes to argv reflected in
> std::arguments, it would require copying arguments on startup which
> may be seen as undesirable even if opt-in. The rough implementation
> sketch I provided is a zero-overhead view over argv, with no
> allocation or caching of things like strlen computations on arguments.
>
> I'd very much appreciate comments, thoughts, and guidance.
>
> Cheers,
> Jeremy
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>