Given your argument, C++14 'auto x{1};' change should not have been
introduced, nor any other change in language.

pt., 23 sie 2019 o 18:23 Timur Doumler <cpp_at_[hidden]> napisał(a):

> 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.
>
>