Date: Sat, 13 Dec 2025 11:03:45 +0000
Just wrote something like this in my day to day c++ programming job:
auto i = somemap.find(key);
auto data = i->second.main_info;
somemap.erase(i);
undecl i; // this would be really nice
// go on to use `data`
I'm mindful that I really, really, don't want to accidentally use `i`
later. And not just me, some other poor dev who comes along later to
update the "go on to use data" code, during a production panic, and
tries to access "i->second.meta_info".
I have to say, c++ introduced the idea of being able to introduce an
identifier anywhere in a block, so the idea of being able to remove an
identifier anywhere after, does have a symmetry that feels right.
I agree that this should be purely about the identifier, not the object
lifetime.
Personally, I don't think it should be allowed to re-use that identifier
later in the block. To me that has all the same confusions and pitfalls
that shadowing has.
Mike.
On 13/12/2025 04:02, SD SH via Std-Proposals wrote:
>
> >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_[hidden]> 代表
> 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];
> *CC:* Sebastian Wittmeier <wittmeier_at_[hidden]>;
> 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.
>
>
auto i = somemap.find(key);
auto data = i->second.main_info;
somemap.erase(i);
undecl i; // this would be really nice
// go on to use `data`
I'm mindful that I really, really, don't want to accidentally use `i`
later. And not just me, some other poor dev who comes along later to
update the "go on to use data" code, during a production panic, and
tries to access "i->second.meta_info".
I have to say, c++ introduced the idea of being able to introduce an
identifier anywhere in a block, so the idea of being able to remove an
identifier anywhere after, does have a symmetry that feels right.
I agree that this should be purely about the identifier, not the object
lifetime.
Personally, I don't think it should be allowed to re-use that identifier
later in the block. To me that has all the same confusions and pitfalls
that shadowing has.
Mike.
On 13/12/2025 04:02, SD SH via Std-Proposals wrote:
>
> >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_[hidden]> 代表
> 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];
> *CC:* Sebastian Wittmeier <wittmeier_at_[hidden]>;
> 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 11:03:51
