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`?

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.