On 1/6/26 20:25, Zhihao Yuan wrote:
> On Tuesday, January 6th, 2026 at 6:15 AM, Jens Maurer via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>>
>
>> Well, once we specify the parameter names and say that the "named parameters"
>> feature works with the standard library, that gives implicit protection against
>> user macros per [reserved.names.general] (might need a slight amendment).
>>
>
>> (What does "global names" mean there? Do they not have external linkage?)
>
> This "implicit protection" is not necessarily
> implied. Imagine a named argument feature
> where functions are declared like this
>
> to_chars_result
> to_chars("first" char* __first,
> "last" char* __last,
> "value" double __val);
>
> then there is no problem if the user
> #define first to something else, it
> merely means the user won't be able
> to call the function with the syntax
>
> to_chars(.first = p, .last = e, .value = 1.0);
>
> because the `first` in the above expands,
> but the header included in the TU that
> has such macro definition isn't affected.
>
> In short, you don't need any "name"
> in the core language at the declaration
> side to specify a named argument, therefore
> there is nothing to reserve.

Right, you can specify the feature in a way that, by definition,
protects against user macros.

My point is that there's no point in optimizing the design in
that respect. Those that "#define x" to something deserve to
be broken.

Jens