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
I think it's pretty likely that keyword arguments would have to be explicitly opt-in. Standard library implementations use reserved names for all their parameters, but approximately no other libraries actually do. And those library's parameter names are, very likely, not considered for external use — and may not want to be considered as part of the API. This is a bit different from reflection, since you can't actually do much with the reflected identifiers (except using in bindings, which is super useful) but now we're talking about use in normal code.
Even when the parameter names are normal-ish, that's probably not something that library authors want users to rely on. For instance, in range-v3, the predicates and projections are pretty consistently named pred and proj, but is that the correct user-facing name? Eric and Casey have never had to think about this before. max(r, .proj=key) is definitely nicer to read than max(r, {}, key), but not as nice as max(r, .key=key) (or ".by" or something else). Lack of explicit opt-in cements a decision that up until now was never even a known decision.
Swift does this via parameter labels, as distinct from parameter names. Where the argument label is user-facing but the parameter name is for the implementation only.
Barry