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]> napisał(a):

> So you propose that this should be well formed?
>
> struct S { explicit operator int() { return 42; } };
>
> int f()
> {
> return { S() };
> }
>
>
>
> Sent from my Samsung Galaxy smartphone.
>
> -------- Original message --------
> From: Maciej Cencora via Std-Proposals <std-proposals_at_[hidden]>
> Date: 8/22/19 16:01 (GMT-05:00)
> To: std-proposals_at_[hidden]
> Cc: Maciej Cencora <m.cencora_at_[hidden]>
> Subject: [std-proposals] Fixing some initialization gotchas
>
> Hi,
>
> with C++17 guaranteed copy initialization, the distinction between direct
> list initialization and copy list initialization has become illusory.
>
> When we initialize a variable with both of these syntaxes:
> 1) T a{ param };
> 2) T a = { param };
>
> We always create a variable of known type, so there is no point in making
> these syntaxes behave differently (currently the only known difference to
> me is the explicit constructor).
>
> So first proposal is merging direct and copy list initialization into one.
>
>
> Second idea is fixing the ambiguities with auto construction.
> auto a{1}; // a is of type int
> auto a = { 1 }; // a is std::initializer_list<int>
>
> I propose to acknowledge the truth, these are ambiguous, let's just make
> list initialization of auto ill formed.
>
> This will force users to use following unambiguous syntaxes:
> auto a = 1;
> or
> std::initializer_list a = { 1 };
>
> Regards,
> Maciej
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>