Just thought



const auto data =

     [&somemap, &key]()

     {

         auto i = somemap.find(key);

         auto data = i->second.main_info;

         somemap.erase(i);

         return data;

     }();



Slightly clunkier, but good enough not to need a language change to add
undecl.




On 13/12/2025 12:32, Sebastian Wittmeier via Std-Proposals wrote:
> AW: [std-proposals] 回复: 回复: 回复: 回复: [PXXXXR0] Add a New Keyword
> ‘undecl’
>
> {
>
> InfoType data;
>
> {
>
> auto i = somemap.find(key);
> data = i->second.main_info;
> somemap.erase(i);
>
> }
> // go on to use `data`
>
> }
>
> Just create an inner block.
>
> ------------------------------------------
>
> InfoType fetchNext(StoreType store, Key key)
>
> {
>
> auto i = store.find(key);
> auto data = i->second.main_info;
> somemap.erase(i);
>
> return data;
>
> }
>
>
> auto data = fetchNext(someMap, key);
> // go on to use `data`
>
> Or extract into a function.
>
> -----Ursprüngliche Nachricht-----
> *Von:* Mike Reed via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Sa 13.12.2025 12:04
> *Betreff:* Re: [std-proposals] 回复: 回复: 回复: 回复: [PXXXXR0] Add a
> New Keyword ‘undecl’
> *An:* std-proposals_at_[hidden];
> *CC:* Mike Reed <mike.reed10_at_[hidden]>;
>
> 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]>
>> <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_[hidden]
>> <std-proposals_at_[hidden]>
>> <mailto:std-proposals_at_[hidden]>
>> *抄送:* Sebastian Wittmeier <wittmeier_at_[hidden]>
>> <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];
>> *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_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
>