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> 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@lists.isocpp.org>
Date: 8/22/19 16:01 (GMT-05:00)
To: std-proposals@lists.isocpp.org
Cc: Maciej Cencora <m.cencora@gmail.com>
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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals