Inner block technique does not work with

const auto data = i->second.main_info;

Yes, I'm aware that creating a function can get round this but I prefer to keep stuff together that belongs together and so, personally, I think the code using undecl is better.  Whether it is better enough for a language change is the question.

Mike.

{

   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@lists.isocpp.org>
Gesendet: Sa 13.12.2025 12:04
Betreff: Re: [std-proposals] 回复: 回复: 回复: 回复: [PXXXXR0] Add a New Keyword ‘undecl’
An: std-proposals@lists.isocpp.org;
CC: Mike Reed <mike.reed10@gmail.com>;

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@lists.isocpp.org> 代表 Sebastian Wittmeier via Std-Proposals <std-proposals@lists.isocpp.org>
发送时间: 2025年12月13日 10:47
收件人: std-proposals@lists.isocpp.org <std-proposals@lists.isocpp.org>
抄送: Sebastian Wittmeier <wittmeier@projectalpha.org>
主题: 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@outlook.com>
Gesendet: Sa 13.12.2025 02:20
Betreff: Re: [std-proposals] 回复: 回复: 回复: [PXXXXR0] Add a New Keyword ‘undecl’
An: std-proposals@lists.isocpp.org;
CC: Sebastian Wittmeier <wittmeier@projectalpha.org>;

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@lists.isocpp.org
 https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals