C++ Logo

STD-PROPOSALS

Advanced search

Subject: Re: [std-proposals] Fixing some initialization gotchas
From: sdkrystian (sdkrystian_at_[hidden])
Date: 2019-08-22 15:36:51


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 intauto 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;orstd::initializer_list a = { 1 };Regards,Maciej



STD-PROPOSALS list run by herb.sutter at gmail.com

Standard Proposals Archives on Google Groups