On 1/4/26 08:32, Jan Schultke wrote:
>
> Things that you might want to put into the narrative:
>
> - Given that several function declarations may have deviating
> parameter names, choosing which one to take is a question.
> But that has been conceptually addressed by reflection
> (take the unique one, otherwise there is none).
>
> - Exposure of function parameter names from the standard library
> is also conceptually addressed by reflection.
>
>
> Yeah, maybe the draft doesn't make it so obvious, but our approach to declarations with different parameter names is the same as for parameter name reflection.
>
> As for standard library functions, they already have a bunch of properties that are observable but which we don't bother to keep stable like:
>
> * Exact expression validity/invalidity (detectable with requires-expressions).
> * Forming function pointers or references to functions (except for addressable functions).
> * Explicitly providing template arguments (in <algorithm>).
> * Reflecting on parameter names and other properties (although I'm not sure we have a policy for this).
>
> Furthermore, the parameter names in the implementation all use reserved identifiers, and we could recommend a warning when a reserved named argument is used, like f(.__x = 0). Consequently, a library-wide policy of not supporting named arguments would be trivial to implement.

I have no concern about the outcome; my concern is to make the connection to
reflection decisions in the narrative of the paper, to show the conceptual
consistency there.

Jens