On 2026-06-16 at 18:02, Ungureanu Radu via Std-Proposals wrote:
> On Tue Jun 16, 2026 at 3:56 PM EEST, Alejandro Colomar wrote:
>> Hi Ungureanu,
>>
>> On 2026-06-16T15:49:20+0300, Ungureanu Radu wrote:
>>> On Tue Jun 16, 2026 at 3:13 PM EEST, Alejandro Colomar wrote:
>>>> Hi Ungureanu,
>>>>
>>>> On 2026-06-16T13:08:18+0300, Ungureanu Radu via Std-Proposals wrote:
>>>>> You bring up a good point, but I think that this can be solved by making
>>>>> it only for named parameters only. For example:
>>>>>
>>>>> void f(X x{5}); // OK
>>>>> void f(X {5}); // Not allowed by the proposed syntax
>>>>>
>>>>> This would avoid changing the current disambiguation rules for something
>>>>> like:
>>>>>
>>>>> X g(X{5});
>>>>>
>>>>> which would continue to be parsed as it is today. Otherwise, the
>>>>> disambiguation would have to get even more complex and could possibly
>>>>> break existing code.
>>>>
>>>> I don't know if this would be ambiguous to a compiler or not. But it
>>>> will most certainly be ambiguous to a human.
>>>>
>>>>
>>>> Have a lovely day!
>>>> Alex
>>>
>>> Hi Alex,
>>>
>>> I am not so sure about this being ambiguous to readers. Let's take an
>>> ordinary declaration for example:
>>>
>>> int x{5};
>>>
>>> Here, the braces are usually understood as initializing x. Similarly,
>>>
>>> void f(int x{5});
>>>
>>> can naturally be read as "x has initializer {5}".
>>>
>>> While a parameter declaration is not an object definition, parameters
>>> still have initialization semantics. When an argument is supplied, the
>>> parameter is initialized with that argument. When it's not supplied,
>>> then the parameter is initialized from the default expression.
>>>
>>> This proposal simply expresses that initialization more directly,
>>> without requiring the type to be repeated in the default argument
>>> expression
>>>
>>> Can you elaborate on the ambiguity you have in mind? I may be missing a
>>> point of confusion here.
>>
>> T f(T x{5});
>> T g(T{5});
>>
>> These two are too similar to have a different meaning, IMO.
>
> Alright this much much clearer thanks. While I do understand the
> concern, the distinction here is already encoded by the presence of the
> parameter name, in this case `x`. My proposal only affects named
> parameters, keeping the existing semantics of the second example as-is.
>

Considering that {}-initalization was introduced to get around some
parsing problems, like

T f(); // function
T f{}; // variable

I would very much try to avoid introducing new combinations where {} is
now hard to parse, or where it depends on the absence of a name.

Instead of having a default parameter with an explicit constructor, you
could instead add an overload

T f() { return f(T{5}); }