Date: Fri, 2 Jul 2021 21:44:59 +0300
https://groups.google.com/a/isocpp.org/g/std-proposals/c/S896xZZJ9qY/m/NvlrZsFtAQAJ
On Fri, Jul 2, 2021 at 7:32 PM connor horman via Std-Proposals <
std-proposals_at_[hidden]> wrote:
>
>
> On Fri, 2 Jul 2021 at 12:04, Thiago Macieira <thiago_at_[hidden]> wrote:
>
>> On Friday, 2 July 2021 08:15:03 PDT connor horman via Std-Proposals wrote:
>> > If the
>> > constructor is invoked with a temporary argument in the position of the
>> > temporary, then the lifetime of that temporary is extended to match the
>> > lifetime of the object under construction
>>
>> Does that include when new'ing such a type?
>>
>> new Type(reference_to_be_lifetime_extended);
>>
>> Does it get extended for the lifetime of the dynamic type? And how does
>> the
>> destructor know to end it?
>>
> No, for that exact reason. I could make it considerably more painful and
> do that (maybe it could store the temporary in that memory, and tell the
> delete expression to destroy it), but that's a rabbit hole I'd rather not
> wander down right now. This is why I mentioned it has to be automatic,
> static, or thread storage duration (though that's in the specification
> section, and the text you cited was in the high level description, so I
> probably should have made the same clear there).
> Basically, the rule applies whenever lifetime extension would have
> applied if the temporary initialized an rvalue reference instead. Though,
> does `new std::initializer_list<int>{1,2,3,4};` lifetime-extend the
> temporary array (I'd assume not, but if so, that may be a potential
> argument).
>
>>
>> PS: the usual discussion about whether this should be an attribute or a
>> full
>> keyword is missing. Remember: a compliant implementation of an attribute
>> is to
>> do nothing.
>>
> I did mention in Drawbacks that this would require an implementation to
> provide the specified behaviour of the attribute. Although, I guess I did
> omit the argument that it should be a keyword (assuming it would be
> implicit). I'm unsure whether making it a full keyword would be a good
> idea, but if making an attribute with a required effect is a non-starter, I
> guess it would be the only other solution (I doubt it could work as a
> contextual keyword).
>
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Software Architect - Intel DPG Cloud Engineering
>>
>>
>>
>> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
On Fri, Jul 2, 2021 at 7:32 PM connor horman via Std-Proposals <
std-proposals_at_[hidden]> wrote:
>
>
> On Fri, 2 Jul 2021 at 12:04, Thiago Macieira <thiago_at_[hidden]> wrote:
>
>> On Friday, 2 July 2021 08:15:03 PDT connor horman via Std-Proposals wrote:
>> > If the
>> > constructor is invoked with a temporary argument in the position of the
>> > temporary, then the lifetime of that temporary is extended to match the
>> > lifetime of the object under construction
>>
>> Does that include when new'ing such a type?
>>
>> new Type(reference_to_be_lifetime_extended);
>>
>> Does it get extended for the lifetime of the dynamic type? And how does
>> the
>> destructor know to end it?
>>
> No, for that exact reason. I could make it considerably more painful and
> do that (maybe it could store the temporary in that memory, and tell the
> delete expression to destroy it), but that's a rabbit hole I'd rather not
> wander down right now. This is why I mentioned it has to be automatic,
> static, or thread storage duration (though that's in the specification
> section, and the text you cited was in the high level description, so I
> probably should have made the same clear there).
> Basically, the rule applies whenever lifetime extension would have
> applied if the temporary initialized an rvalue reference instead. Though,
> does `new std::initializer_list<int>{1,2,3,4};` lifetime-extend the
> temporary array (I'd assume not, but if so, that may be a potential
> argument).
>
>>
>> PS: the usual discussion about whether this should be an attribute or a
>> full
>> keyword is missing. Remember: a compliant implementation of an attribute
>> is to
>> do nothing.
>>
> I did mention in Drawbacks that this would require an implementation to
> provide the specified behaviour of the attribute. Although, I guess I did
> omit the argument that it should be a keyword (assuming it would be
> implicit). I'm unsure whether making it a full keyword would be a good
> idea, but if making an attribute with a required effect is a non-starter, I
> guess it would be the only other solution (I doubt it could work as a
> contextual keyword).
>
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Software Architect - Intel DPG Cloud Engineering
>>
>>
>>
>> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2021-07-02 13:45:17