I doubt that as well.

Apart from the code breakage and silent behaviour change aspects, there's also the teaching aspect. I find it difficult enough to teach initialisation rules as they are. Imagine having to teach folks that auto a{1}; means one thing in C++14, another thing in C++17, and yet something else in C++23.

Cheers,
Timur

> On 23 Aug 2019, at 18:00, Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
>
> On Fri, 23 Aug 2019 at 18:46, Maciej Cencora <m.cencora_at_[hidden]> wrote:
>>>> Currently only x1 and x2 has same type, x4 does not compile, x1 and x2 compiles only if you include initializer_list header.
>>>> And x1 type is different then x3.
>>>> This is complete bonkers!
>>>
>>> Indeed it is. But in order to get x3, some parties insisted on keeping
>>> x1/x2 working as they were, so that's the compromise we have.
>>
>>
>> A compromise that leads to even more problems.
>
> A compromise that solved the problem it was aiming to solve, too.
>
>>>> With my proposal the only allow auto declaration would be in following form:
>>>> auto x = y;
>>>> which is unambiguous, has no corner cases, and works just as right now.
>>>
>>> Yeah, and then T a{x}; works but auto a{x} doesn't, so yeah, you do
>>> have corner cases.
>>
>>
>> Fine, lets call it a corner case, but it is still way more saner and simpler to remember, than what we have now (and if you will forget that limitation, the compiler will immediately remind you).
>
> You're more than welcome to try proposing such a breaking change. I
> doubt it'll go well.