Date: Fri, 02 Jan 2026 22:22:25 +0000
> On Friday, January 2nd, 2026 at 11:49 AM, Jan Schultke via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>>> What about a mixture of positional and named parameters?
>>
>> I have some thoughts on that here: https://eisenwave.github.io/cpp-proposals/named-args.html#mixing-named-and-positional-arguments
>> Things can get pretty confusing when mixing of positional and named arguments is permitted. The low-hanging fruit is to allow positional arguments at the start of the argument list, which has the obvious behavior of working exactly like positional arguments normally do.
>>
>> More recent versions of Kotlin allow you to mix positional and named arguments in the middle, but only within a prefix of arguments where if an argument is named, it needs to be in the same position as if it was provided positionally. For example, f(.first=0, 1) is valid, but f(.second=1, 0) is not. However, what Kotlin eventually made valid is unnecessarily ambitious for the first version of such a feature.
I wonder if the mixed-use use case is a real thing, though? It's clearly a question to be addressed, but I imagine that people who want named parameters will always use them, and those who don't will never use them (unless/until forced).
That said, variadic functions will present an interesting problem or two.
>
>
>>> What about a mixture of positional and named parameters?
>>
>> I have some thoughts on that here: https://eisenwave.github.io/cpp-proposals/named-args.html#mixing-named-and-positional-arguments
>> Things can get pretty confusing when mixing of positional and named arguments is permitted. The low-hanging fruit is to allow positional arguments at the start of the argument list, which has the obvious behavior of working exactly like positional arguments normally do.
>>
>> More recent versions of Kotlin allow you to mix positional and named arguments in the middle, but only within a prefix of arguments where if an argument is named, it needs to be in the same position as if it was provided positionally. For example, f(.first=0, 1) is valid, but f(.second=1, 0) is not. However, what Kotlin eventually made valid is unnecessarily ambitious for the first version of such a feature.
I wonder if the mixed-use use case is a real thing, though? It's clearly a question to be addressed, but I imagine that people who want named parameters will always use them, and those who don't will never use them (unless/until forced).
That said, variadic functions will present an interesting problem or two.
>
Received on 2026-01-02 22:22:32