Date: Mon, 09 Sep 2024 09:11:34 +0100
On 9 September 2024 07:09:07 BST, Richard Hodges via Std-Proposals <std-proposals_at_[hidden]> wrote:
>On Sat, 7 Sept 2024 at 17:37, Jeremy Rifkin via Std-Proposals <
>std-proposals_at_[hidden]> wrote:
>
>> Hello,
>>
>> I'd like to propose adding int main(std::span<std::string_view> args) as
>> a standard signature for main.
>>
>
>This would cause a regression in functionality.
>
>The signature for main is: int* main(*int argc*,* char* argv[]*)*
>
>argv is a mutable array of string pointers. Existing programs take
>advantage of this when parsing program arguments. They re-order the
>pointers in order to group options and trailing arguments.
The proposed interface here would allow the same reordering, it's not span<const ...>. Granted it would not allow modifying the arguments themselves, but that wasn't your objection.
>The proposed change would break all these programs that have worked well
>for something like 40 years.
Existing programs could always keep using the existing main signature.
>Allowing access to command line arguments in places other than main
>(mentioned further down the thread) is a bad idea precisely because of this
>mutability.
That just highlights that library code generally shouldn't silently access command line arguments, they belong to the application. That's true regardless if they are mutable or not.
OTOH if the arguments are owned by the application then the only use case for accessing them outside of main is to access them before main. Whether that use case is worth supporting is a good question, but with inline variables most SIOF issues could be sorted out.
Somehow accessing env outside of main works out too, although it has the same mutability issue. Although I would resolve that differently as "just forget setenv exists" in most cases.
>If it ain't broke...
I generally agree though, it's easy enough to have `my_main` with whatever sensible signature I want and call it from main.
>>
>> Motivation:
>> - Modernization
>> - Ergonomics
>> - Teachability
>> - Modern C++ through and through instead of 'what's a char**' and
>> 'argv[1] == "--help" is a footgun, beware'
>>
>> Considerations:
>> - There would be slight startup overhead in constructing the
>> std::string_views and underlying array of string views, however, this
>> would be entirely opt-in
>> - It would probably add some implementation complexity
>> - This would be an aspect of the core language which depends on the
>> standard library. I don't love that, but, there is precedence for this
>> sort of thing
>> - Direct mutability of the argument contents would be lost
>>
>> I would make a reference implementation as part of the proposal.
>>
>>
>> Cheers,
>> Jeremy
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>On Sat, 7 Sept 2024 at 17:37, Jeremy Rifkin via Std-Proposals <
>std-proposals_at_[hidden]> wrote:
>
>> Hello,
>>
>> I'd like to propose adding int main(std::span<std::string_view> args) as
>> a standard signature for main.
>>
>
>This would cause a regression in functionality.
>
>The signature for main is: int* main(*int argc*,* char* argv[]*)*
>
>argv is a mutable array of string pointers. Existing programs take
>advantage of this when parsing program arguments. They re-order the
>pointers in order to group options and trailing arguments.
The proposed interface here would allow the same reordering, it's not span<const ...>. Granted it would not allow modifying the arguments themselves, but that wasn't your objection.
>The proposed change would break all these programs that have worked well
>for something like 40 years.
Existing programs could always keep using the existing main signature.
>Allowing access to command line arguments in places other than main
>(mentioned further down the thread) is a bad idea precisely because of this
>mutability.
That just highlights that library code generally shouldn't silently access command line arguments, they belong to the application. That's true regardless if they are mutable or not.
OTOH if the arguments are owned by the application then the only use case for accessing them outside of main is to access them before main. Whether that use case is worth supporting is a good question, but with inline variables most SIOF issues could be sorted out.
Somehow accessing env outside of main works out too, although it has the same mutability issue. Although I would resolve that differently as "just forget setenv exists" in most cases.
>If it ain't broke...
I generally agree though, it's easy enough to have `my_main` with whatever sensible signature I want and call it from main.
>>
>> Motivation:
>> - Modernization
>> - Ergonomics
>> - Teachability
>> - Modern C++ through and through instead of 'what's a char**' and
>> 'argv[1] == "--help" is a footgun, beware'
>>
>> Considerations:
>> - There would be slight startup overhead in constructing the
>> std::string_views and underlying array of string views, however, this
>> would be entirely opt-in
>> - It would probably add some implementation complexity
>> - This would be an aspect of the core language which depends on the
>> standard library. I don't love that, but, there is precedence for this
>> sort of thing
>> - Direct mutability of the argument contents would be lost
>>
>> I would make a reference implementation as part of the proposal.
>>
>>
>> Cheers,
>> Jeremy
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
Received on 2024-09-09 08:11:40