The arguments() function should not return const arguments_view&. For a long time, functions returning global object references in the standard library have caused too many issues with multi-threading and cross-dynamic-linking-library, even though dynamic linking don’t exist in the C or C++ standards. One solution is to design it as an entry point so that it won’t be called in multi-threading and cross-dll/so. Alternatively, use the information provided by the existing CRT to ensure that it never allocates memory. If neither of these methods is feasible, I prefer that arguments() allocates memory and returns a brand new argument_view each time it is called, rather than implicitly creating an object in some mysterious place. In actual use, arguments() should only be called once at the logical entry point of the program, so the current over-designed scheme is unnecessary. Although I’m not a member of WG21/WG14, I strongly oppose the current design. The lazy-initialized singleton has caused immense suffering in the standard library. It has never been zero-cost.

Best regards,
YexuanXiao
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]>
Sent: Monday, September 30, 2024 8:46
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Jeremy Rifkin <jeremy_at_[hidden]>
Subject: [std-proposals] A draft for a std::arguments proposal

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.

Draft: https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjeremy-rifkin.github.io%2Fproposals%2Fdrafts%2Fcpp%2Farguments-draft-1.html&data=05%7C02%7C%7C3a81a4755883405afd0708dce0e96847%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638632540312163421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=0tBrxMSiTQz62MGDKs4NPqQvamo1WvKUo3MXU72y6gc%3D&reserved=0<https://jeremy-rifkin.github.io/proposals/drafts/cpp/arguments-draft-1.html>
Very rough sketch to get a feel for the interface: https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgodbolt.org%2Fz%2Fd7zvKc4xj&data=05%7C02%7C%7C3a81a4755883405afd0708dce0e96847%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638632540312182472%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=BnU%2BdCtXHQreZal4zCVYHEZVXUu%2F93Iaq%2BfMQNo6byk%3D&reserved=0<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://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=05%7C02%7C%7C3a81a4755883405afd0708dce0e96847%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638632540312190487%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=gkOvVCK58xLzuo6xEzlzTtvSkX0%2BHUqrn7P6vJUVXAs%3D&reserved=0<https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>