On Mon, Jan 5, 2026 at 2:28 PM Ivan Lazaric via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> If it was opt-in, does that mean C libraries would never come with named parameters enabled?
> There's a lot of C functions I would love to use named parameters on.

But those libraries were not built for that. There's no contract about
keeping parameter names the same.

One of the issues with discussions around named parameters is that
there are broadly two use cases for the feature that look similar but
are functionally quite different, both at the call site and from the
library author's perspective.

One case is where there's a function that needs a bunch of parameters
and distinguishing them by order or type isn't viable. This makes
calling such functions quite cumbersome of a task, and reading what a
function call is doing requires constantly switching back and forth
between the call site and the function declaration.

Because everyone knows that such calls are cumbersome, writers of
libraries are discouraged from writing such interfaces. We've
developed a number of ways to avoid this kind of thing: two-stage
construction, parameters-as-structs, etc.

>From this perspective, opt-in named parameters are fine. Why? Because
the function *did not exist* before. Because of the problem of writing
fat interfaces, people avoided writing them. So what opt-in named
parameters does is unblock the ability to engage with such interfaces,
both for the library writer and the caller.

Note that named parameters in these cases are not "documentation";
they are a fundamental part of the function's interface. The function
*would not* be written the way it is if named parameters didn't exist,
and function calls on such an interface often need to use named
parameters in order to be comprehensible at all. The parameter names
are as much a part of the function's interface as the parameter types.

The other case is this. There's a function that takes two parameters
of the same type; one of them is input and the other is output
(memcpy, for example). There might sometimes be some confusion as to
which is which, and different libraries have different conventions. So
it would be useful at the call site to say which is which.

This case is where opt-out named parameters would be wanted. But also
note that this case is *only* meaningful from the caller's
perspective. The library writer did not write the function to be
called this way, and they certainly do not intend for the parameter
names to be considered as much a part of the function's interface as
its types. Furthermore, the ambiguity is often pretty minor,
especially compared to the first case.

> I am assuming one could add redeclarations with the opt-in to enable.
> Wondering how often code will break because of conflicting redeclarations.
> (your libA depends on libB and libC, both of which depend on libD and introduce redeclarations for named parameters)
>
> If the mechanism was implicit / opt-out, I would have the following mindset:
> If the library doesn't explicitly state they keep their parameter names stable, I would be aware using them can break on upgrades, and avoid using them without a really good reason
> - the good reason could be "I won't be upgrading that often, and I am fine fixing up the compilation errors if they ever happen, and they improve my ergonomics sufficiently"

If they "improve my ergonomics" that much, couldn't you just write
some wrapper functions and call it a day? I mean, if you're going
through the trouble of redeclaring these functions, just write a
wrapper.