On Sat, Dec 13, 2025 at 01:53:26PM +0000, Mike Reed via Std-Proposals wrote:
> 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.

Yes. The problem is if you need to perform some flow change in the outer
function, e.g. if somemap.find could fail.

With undecl you can just do what is needed.

With inner scopes it works but adds an indentation level for the function.

With lambdas it doesn't work without exceptions or longjmp.

auto i = somemap.find(key);
if (i == somemap.end())
  return error;
auto data = std::move(i->second.main_info);
somemap.erase(i);
undecl i;
/* do whatever with data */

/MF

>
>
>
> 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
> >
> >

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