On Tuesday, January 6th, 2026 at 11:33 AM, Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> wrote:

> Why is the declaration not affected? Because the parameter name is written as string literal?
>

> to_chars_result
> to_chars("first" char* __first,
> "last" char* __last,
> "value" double __val);

Yes. Only identifier tokens may be expanded
during preprocessing.

(to be more precise in terminology, __first is
 a parameter name, "first" is a parameter label
 or whatever new grammar production you plan
 to call it)

> > -----Ursprüngliche Nachricht-----
> > Von: Zhihao Yuan via Std-Proposals <std-proposals_at_[hidden]>
> > Gesendet: Di 06.01.2026 20:26
> > Betreff: Re: [std-proposals] Labelled parameters
> > Anlage: signature.asc
> > An: std-proposals_at_[hidden];
> > CC: Zhihao Yuan <zy_at_[hidden]>;
> > 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.
> >

> > --
> > Zhihao Yuan, ID lichray
> > The best way to predict the future is to invent it.
> > _______________________________________________
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals