I think you all don't need this key word. You can use a scope such as if(){ scope}, lambda[]()->{scope}

获取Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Jonathan Wakely via Std-Proposals <std-proposals_at_[hidden]>
Sent: Thursday, December 18, 2025 3:52:30 PM
To: C++ Proposals <std-proposals_at_[hidden]>
Cc: Jonathan Wakely <cxx_at_kayari.org>; Mike Reed <mike.reed10_at_[hidden]>
Subject: Re: [std-proposals] 回复: 回复: 回复: 回复: [PXXXXR0] Add a New Keyword ‘undecl’



On Sat, 13 Dec 2025, 11:04 Mike Reed via Std-Proposals, <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:

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.

This is possible today using the _ identifier.

auto _ = somemap.find(key);
auto data = _->second.main_info;
somemap.erase(_);
int _ = 0;

Now you have two _ variables in scope and so it's an error to refer to it.




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]p.org><mailto:std-proposals-bounces_at_[hidden]> 代表 Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]><mailto:std-proposals_at_[hidden]>
发送时间: 2025年12月13日 10:47
收件人: std-proposals_at_lists.isocpp.org<mailto:std-proposals_at_[hidden]> <std-proposals_at_[hidden]><mailto:std-proposals_at_[hidden]>
抄送: Sebastian Wittmeier <wittmeier_at_projectalpha.org><mailto: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]><mailto: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]<mailto:std-proposals_at_[hidden]>;
CC: Sebastian Wittmeier <wittmeier_at_[hidden]><mailto: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.


--
Std-Proposals mailing list
Std-Proposals_at_lists.isocpp.org<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals