> C++ has been around for 40(?) years.
> C has been around for longer than that.

> In all that time, there has not been a single program that could not be written because a programmer could not arbitrarily access command line arguments from any old place in the program.

That's not what this proposal is about.

Jeremy

On Sun, Oct 13, 2024 at 6:01 PM Richard Hodges via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
>
>
> On Mon, 30 Sept 2024 at 02:47, Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> 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.
>
>
> C++ has been around for 40(?) years.
> C has been around for longer than that.
>
> In all that time, there has not been a single program that could not be written because a programmer could not arbitrarily access command line arguments from any old place in the program.
>
> Is this really worth standardising?
>
> Environment variables already provide a vector for injecting arbitrary data into a program.
>
> Might it not be a better idea to provide it as a compiler extension and see if anyone actually uses it?
>
> My suspicion is that anyone reviewing code that uses it will baulk at the audacity of the idea.
>
>
>
>
>
>>
>>
>> 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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals