Date: Fri, 23 Aug 2019 10:01:08 +0200
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]> 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]> napisał(a):
>
>>
>>
>> On Thu, Aug 22, 2019 at 4:46 PM Maciej Cencora via Std-Proposals <
>> 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]> 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
>>
>
>
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]> 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]> napisał(a):
>
>>
>>
>> On Thu, Aug 22, 2019 at 4:46 PM Maciej Cencora via Std-Proposals <
>> 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]> 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 03:03:23