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@lists.isocpp.org> 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@technion.ac.il> napisał(a):
Have you seen Nikolai Josuttis's talk, “The Nightmare of Initialization
in C++”
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@gmail.com
> <mailto:tvaneerd@gmail.com>> 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@gmail.com
>     <mailto:tvaneerd@gmail.com>> napisał(a):
>
>
>
>         On Thu, Aug 22, 2019 at 4:46 PM Maciej Cencora via Std-Proposals
>         <std-proposals@lists.isocpp.org
>         <mailto:std-proposals@lists.isocpp.org>> 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@lists.isocpp.org
>             <mailto:std-proposals@lists.isocpp.org>> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals