C++ Logo

STD-PROPOSALS

Advanced search

Subject: Re: [std-proposals] Fixing some initialization gotchas
From: Eyal Rozenberg (eyalroz_at_[hidden])
Date: 2019-08-23 04:15:41


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_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]>> 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]>> 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]>> 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 list run by herb.sutter at gmail.com

Standard Proposals Archives on Google Groups