Hi thanks for the reply and thoughts,

> I think, std::arguments name is too generic and may encroach on
> something
> associated with function arguments in the future. And the name is
> confusing
> today for the same reason.

Good points. I went with std::arguments because that's the form the
committee had previously considered.

I think program_options and command_line would be confusing, the first
because of being different from Boost.ProgramOptions and the second
because it's not the full command line, just arguments, unless the later
were std::command_line::arguments. I think std::program_arguments or
maybe std::argv might be best.

Cheers,
Jeremy


On Sep 30 2024, at 3:16 am, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:

> On September 30, 2024 3:47:08 AM Jeremy Rifkin via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>
>> Hi,
>> I'm drafting a proposal to add std::arguments which would provide an
>> encoding-friendly and modern interface for accessing program arguments.
>
> [...]
>
>> I'd very much appreciate comments, thoughts, and guidance.
>
> I think, std::arguments name is too generic and may encroach on
> something
> associated with function arguments in the future. And the name is
> confusing
> today for the same reason.
>
> A few better alternatives are: program_arguments, command_line,
> program_options.
>
> Past experience: there exists Boost.ProgramOptions, which is a well
> known
> library for working with command line. While the library design and
> goals
> are very different from the proposal, it sets existing nomenclature
> for the
> problem domain.
>
>
>
>