Thanks Yexuan and Tiago,

> For a long time, functions returning global object references in the
> standard library have caused too many issues with multi-threading

What examples do you have in mind? Note that in this case the object is read-only.

> One solution is to design it as an entry point

Are you suggesting to construct the object before the entry point or are
you suggesting a new entry point making this information available?
Unfortunately I don't think either are viable options. Previous
committee discussion and polling indicates a strong desire to avoid both
of these.

> 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.

> C++ is an object-oriented capable language.
> std::arguments could be a class, with a constructor that does stuff.
> It would solve a lot of design problems.

This is possible and it may be sensible. One nice benefit would be the
user could control the lifetime of arguments object, if allocations are
needed. The main concern that would come to mind for me is redundancy
with multiple parts of a codebase creating their own arguments object
and different parts of the code could see different arguments, e.g. if
one std::arguments is used before main, then main changes argv, then
somewhere else makes a new arguments object. (This is mainly a concern
if it's decided it's undesirable to leave std::arguments in the case of
argv modifications unspecified)

> In actual use, arguments() should only be called once at the logical
> entry point of the program

I think it could actually be quite common to access arguments in more
than one place in the program, that's part of the motivation for this
proposal. E.g. libraries checking for arguments they recognize,
accessing arguments for debugging reasons, etc.

Cheers,
Jeremy

On Oct 3 2024, at 7:14 am, Tiago Freire via Std-Proposals
<std-proposals_at_[hidden]> wrote:

> C++ is an object-oriented capable language.
>
> std::arguments could be a class, with a constructor that does stuff.
> It would solve a lot of design problems.
>
>
>
>
>
> From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf
> of Yexuan Xiao via Std-Proposals <std-proposals_at_[hidden]>
> Sent: Thursday, October 3, 2024 1:35:39 PM
> To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> Cc: Yexuan Xiao <bizwen_at_[hidden]>
> Subject: Re: [std-proposals] A draft for a std::arguments proposal
>
>
> 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
> 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
>
> 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
>
> --
>
> Std-Proposals mailing list
>
> Std-Proposals_at_[hidden]
>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals