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_lists.isocpp.org> On Behalf Of Jeremy Rifkin via Std-Proposals
Sent: Monday, September 30, 2024 2:47 AM
To: std-proposals_at_lists.isocpp.org
Cc: Jeremy Rifkin <jeremy_at_rifkin.dev>
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