Date: Wed, 23 Jul 2025 14:29:15 +0200
I have certainly been tempted to use the "char **envp" variant of main. As
others have mentioned, maybe it makes more sense to standardize proper
functions to get and set environment variables (preferably with
std::string/std::string_view and not char*). It might still be interesting
to have the envp parameter to know the initial state of environment
variables (should be const then).
I personally don't see a point in allowing void main(). I'd rather see int
main(), i.e. no arguments but still int, standardized because it already
allows to drop the return.
It would make a lot more sense, as Hans mentioned, to finally use C++ types
in the argument list. It is quite annoying to have functions taking a
"char*" anywhere in standard functions. It was most annoying (for a long
time) for std::fstream that you couldn't pass a std::string. I personally
believe that standard APIs should always promote the usage of std::string
(at least, maybe even std::vector or std::map). We are living in an age
where we talk about memory safety and std::string instead of char*
certainly helps.
I personally also like const correctness, so I'm definitely for making
everything const in main()'s arguments.
On Tue, Jul 22, 2025 at 8: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 am using it, but I found std::string_view not useful because of the lack
> of conversions to std::string.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
others have mentioned, maybe it makes more sense to standardize proper
functions to get and set environment variables (preferably with
std::string/std::string_view and not char*). It might still be interesting
to have the envp parameter to know the initial state of environment
variables (should be const then).
I personally don't see a point in allowing void main(). I'd rather see int
main(), i.e. no arguments but still int, standardized because it already
allows to drop the return.
It would make a lot more sense, as Hans mentioned, to finally use C++ types
in the argument list. It is quite annoying to have functions taking a
"char*" anywhere in standard functions. It was most annoying (for a long
time) for std::fstream that you couldn't pass a std::string. I personally
believe that standard APIs should always promote the usage of std::string
(at least, maybe even std::vector or std::map). We are living in an age
where we talk about memory safety and std::string instead of char*
certainly helps.
I personally also like const correctness, so I'm definitely for making
everything const in main()'s arguments.
On Tue, Jul 22, 2025 at 8: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 am using it, but I found std::string_view not useful because of the lack
> of conversions to std::string.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2025-07-23 12:30:02