On 05/01/2026 14:54, Jan Schultke via Std-Proposals wrote:
> Or simply define `foo(.Type{X})` as "Find `Type` using ADL based on
> `foo`"
>
> And then add options for generic proxies to use it too, like:
>
> ```
> void proxy(auto y) uses_namespace_of(my_lib::foo)
> {
> my_lib::foo(y);
> }
>
> proxy(.Type{1}); // find `my_lib::Type`
> ```
>
> Only problem would be if you had two `foo` from diffrent namespaces
> and both could find some `Type` based on ADL.
>
> The whole strong type stuff feels like piling several layers of
> complicated machinery on top of what is a very simple feature in
> languages, typically. At work, I literally just wrote some Kotlin a
> minute ago:
>
> haystack.contains(it, ignoreCase = true)
>
>
> Is it really too much to ask to have a simple mechanism that lets you
> pass values of fundamental type instead of adding a layer of proxy types
> and ADL? If you're going to create types for each parameter anyway, then
> adding a new core language feature just so you can write .Type{1}instead
> of ns::Type{1}is probably not worth the effort.
>

Unfortunately, the answer is yes, it is apparently too much to ask.

Like many features that are available in modern languages but missing,
complicated or ugly in C++, named parameters can be easily and
consistently supported in a language when they are designed in from the
start. Finding a syntax for named parameters is easy - finding a way to
add them to the existing language without breaking compatibility, ABI's
and existing code, and doing so in a manner that fits the rest of the
language now and in the future - that's the hard part.