> On 22 Jul 2025, at 22:00, Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Tue, Jul 22, 2025 at 2:31 PM Hans Åberg via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>>> On 22 Jul 2025, at 19:50, Jan Schultke via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>>
>>>> the bang for the buck isn't there, and this sort of small tweaks to
>>>> const-correctness of argv and the return type of main are not a good
>>>> use of the committee time.
>>>
>>> How would you feel about it if the proposal also included
>>> standardization of a third "char** envp" parameter, which every
>>> implementation already supports?
>>>
>>> Would that sufficiently broaden the scope of the proposal to be worth
>>> committee time?
>>
>> It might admit signatures of the form
>> int main(std::vector<std::string> arg, std::unordered_map<std::string, std::string> env);
>> where std::string might be replaced by std::string_view, and std::unordered_map by std::map, easily implemented from
>> int main(int argc, char *argv[], char* envp[]);
>
> I don't use main's arguments in my programming, but would something
> like this actually be useful? It seems more like convenience. Would it
> actually solve some real problem that programs that take command line
> arguments actually have? If people are using tools to parse command
> lines, are they more likely to take `vector<string>` than `argc/argv`?

I did so to avoid having to use such external tools.

> Especially when it comes to environment variables, I wonder if having
> some way to just query the set of environment variables would be a
> more reasonable alternative than making a new main function. And
> preferably not binding such interfaces to specific containers.

Not on POSIX (Unix-like) computers, it is just an array of C-strings, where the parts are separated by '='.

So it means that without it, in order to use it, one will have to do some figuring out and implement something similar.