If it's zero-cost carry on, but when you present interfaces such as std::arguments.at(1) this would suggest at least a global object, which wouldn't be zero-cost.
Then you have an accessor method at, which on Windows if it was stateless would require always parsing up to the token n, which would be extremely inefficient, not to mention unimplementable due to the presence of escape characters while you return a view.

If this was an object instead, that a user would need to instantiate in order to use, then you could have state, and this wouldn't be a problem.

________________________________
From: Jeremy Rifkin <jeremy_at_[hidden]>
Sent: Tuesday, October 1, 2024 1:02:34 AM
To: Tiago Freire <tmiguelf_at_[hidden]>
Cc: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Subject: Re: [std-proposals] A draft for a std::arguments proposal

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
>