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.