IIUC, you are proposing to make existing code like auto x{1}; ill-formed that is well-formed today.

Further, you are proposing to silently change the behaviour of existing code. Imagine a class with an explicit c’tor and a non explicit one: your proposal might silently change which c’tor gets called.

When proposing such breakage, you should really have a good argument why that’s worth it, and study how much real-world code would actually be affected. How many such initailisations per MLoC exist in existing large code bases?

Further, the distinction between direct-list-init and copy-list-init has parallels with the much older distinction between direct-init and copy-init. You would be breaking that consistency on a conceptual level.

Timur

> On 23 Aug 2019, at 11:40, Maciej Cencora via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Yes, I have seen it and it was one of motivations to write this proposal.
>
> pt., 23 sie 2019 o 11:15 Eyal Rozenberg <eyalroz_at_[hidden] <mailto:eyalroz_at_[hidden]>> napisał(a):
> Have you seen Nikolai Josuttis's talk, “The Nightmare of Initialization
> in C++”
> https://www.youtube.com/watch?v=7DTlWPgX6zs <https://www.youtube.com/watch?v=7DTlWPgX6zs>
> ?
>
> If not, give it a watch; I remember it presents all sorts of eccentric
> use case and rationales. Josuttis says that he ends up in a state where
> he is not sure what exactly needs to be "fixed". That would give you
> perspective on your proposal (and perhaps shoot it down - I'm not sure.)
>
> Eyal
>
> On 23/08/2019 11:01, Maciej Cencora via Std-Proposals wrote:
> > If it is already, then yes, and removing the explicit constructor
> > requirement for copy-list initialization in return statement won't
> > change that.
> >
> > Anyway the main point of this proposal is to unify initialization
> > behavior a little more in context of variable/member declaration, so
> > changing explicit constructor requirement in this case could be dropped
> > if LEWG has strong objections.
> >
> > So what do you think?
> >
> >
> >
> >
> >
> > pt., 23 sie 2019 o 01:05 Tony V E <tvaneerd_at_[hidden] <mailto:tvaneerd_at_[hidden]>
> > <mailto:tvaneerd_at_[hidden] <mailto:tvaneerd_at_[hidden]>>> napisał(a):
> >
> > I think there was a convincing examples from Howard Hinnant like
> >
> > chrono::seconds f()
> > {
> > Long();
> > Function();
> > ...
> > if (condition)
> > return i;
> >
> > Morestuff();
> > Etc();
> >
> > return chrono::minutes(j);
> > }
> >
> > Is that function correct?
> >
> > Sent from my BlackBerry portable Babbage Device
> > *From: *Maciej Cencora
> > *Sent: *Thursday, August 22, 2019 4:56 PM
> > *To: *Tony V E
> > *Cc: *sotrdg sotrdg via Std-Proposals
> > *Subject: *Re: [std-proposals] Fixing some initialization gotchas
> >
> >
> > And what were LEWG arguments for saying no here?
> >
> > czw., 22 sie 2019 o 22:55 Tony V E <tvaneerd_at_[hidden] <mailto:tvaneerd_at_[hidden]>
> > <mailto:tvaneerd_at_[hidden] <mailto:tvaneerd_at_[hidden]>>> napisał(a):
> >
> >
> >
> > On Thu, Aug 22, 2019 at 4:46 PM Maciej Cencora via Std-Proposals
> > <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>
> > <mailto:std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>> wrote:
> >
> > Yes.
> >
> > After all you are explicit about the return type of the
> > function (you specified it in function definition), so why
> > would you not want this to work? There is no possibility for
> > amibiguity here.
> >
> > czw., 22 sie 2019 o 22:36 sdkrystian via Std-Proposals
> > <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>
> > <mailto:std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>> napisał(a):
> >
> > So you propose that this should be well formed?
> >
> > struct S { explicit operator int() { return 42; } };
> >
> > int f()
> > {
> > return { S() };
> > }
> >
> >
> > Having explicit work here has been voted on by the committee in
> > the past, and LEWG strongly said No.
> >
> >
> > --
> > Be seeing you,
> > Tony
> >
> >
> >
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals