Date: Fri, 23 Aug 2019 11:40:32 +0200
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_at_[hidden]> 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_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
> >
> >
> >
>
pt., 23 sie 2019 o 11:15 Eyal Rozenberg <eyalroz_at_[hidden]> 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_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
> >
> >
> >
>
Received on 2019-08-23 04:42:46