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.

Best regards,
Radu