Date: Sat, 13 Dec 2025 04:02:58 +0000
>Moving has to keep the object in a valid state.
The destructor will be called same as origin.
>Calling the destructor would probably lead to double-destruction.
Moving and destructing are additional operations. This feature not be used to do these things.
Calling destructor leads double-destruction. I hope there is a way to end objects early and explicitly if we need, but using obj.~T() or std::destruct_at(&obj) may be incorrect.
It isn't directly related to the feature we are talking, sorry that I talking far ahead.
________________________________
发件人: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> 代表 Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>
发送时间: 2025年12月13日 10:47
收件人: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
抄送: Sebastian Wittmeier <wittmeier_at_[hidden]>
主题: Re: [std-proposals] 回复: 回复: 回复: [PXXXXR0] Add a New Keyword ‘undecl’
The cleanest approach is to relocate (trivial relocatability was delayed for after C++26) the object into nothing.
That would probably just destruct it, but the compiler would know, not to destruct it a second time.
Moving has to keep the object in a valid state.
Calling the destructor would probably lead to double-destruction.
-----Ursprüngliche Nachricht-----
Von: SD SH <Z5515zwy_at_[hidden]>
Gesendet: Sa 13.12.2025 02:20
Betreff: Re: [std-proposals] 回复: 回复: 回复: [PXXXXR0] Add a New Keyword ‘undecl’
An: std-proposals_at_[hidden]p.org;
CC: Sebastian Wittmeier <wittmeier_at_[hidden]rg>;
Thinking of more cases, we can move the object, call the destructor, use std::destroy_at or just do nothing until it end, so changing lifetimes is not necessary and it will introduce trouble in managing a object.
The destructor will be called same as origin.
>Calling the destructor would probably lead to double-destruction.
Moving and destructing are additional operations. This feature not be used to do these things.
Calling destructor leads double-destruction. I hope there is a way to end objects early and explicitly if we need, but using obj.~T() or std::destruct_at(&obj) may be incorrect.
It isn't directly related to the feature we are talking, sorry that I talking far ahead.
________________________________
发件人: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> 代表 Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>
发送时间: 2025年12月13日 10:47
收件人: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
抄送: Sebastian Wittmeier <wittmeier_at_[hidden]>
主题: Re: [std-proposals] 回复: 回复: 回复: [PXXXXR0] Add a New Keyword ‘undecl’
The cleanest approach is to relocate (trivial relocatability was delayed for after C++26) the object into nothing.
That would probably just destruct it, but the compiler would know, not to destruct it a second time.
Moving has to keep the object in a valid state.
Calling the destructor would probably lead to double-destruction.
-----Ursprüngliche Nachricht-----
Von: SD SH <Z5515zwy_at_[hidden]>
Gesendet: Sa 13.12.2025 02:20
Betreff: Re: [std-proposals] 回复: 回复: 回复: [PXXXXR0] Add a New Keyword ‘undecl’
An: std-proposals_at_[hidden]p.org;
CC: Sebastian Wittmeier <wittmeier_at_[hidden]rg>;
Thinking of more cases, we can move the object, call the destructor, use std::destroy_at or just do nothing until it end, so changing lifetimes is not necessary and it will introduce trouble in managing a object.
Received on 2025-12-13 04:03:07
