Date: Wed, 10 Dec 2025 10:01:53 -0600
Hi,
It is extremely unlikely something like this would ever be added to C++.
Such a change would require a lot of motivation, and this paper doesn't
currently provide much motivation.
If the motivation is reusing the name, consider what rust has done with
shadowing:
let x = foo();
let x = x.transform(); // new x shadows old x, can be a new type
There is precedent for this mechanism in C++ now with P2169.
If the motivation is compiler optimization, this is a micro-optimization
and would be harmful as a language feature. Compilers can very easily
identify when objects in a function are dead and reclaim storage and
registers.
If the motivation is ending an object's lifetime as far as the C++ abstract
machine is concerned and calling destructors, just use std::optional:
std::optional<T> thing;
...
thing.reset(); // destroy the object, call the destructor
This is much more simple and straightforward to reason about than the
language feature you're proposing. If you are concerned about the overhead
from the flag std::optional stores to indicate if a value is contained or
not, this is something compilers should be able to optimize with relative
ease, though the overhead would be completely negligible in almost all
cases even if it didn't.
Cheers,
Jeremy
On Tue, Dec 9, 2025 at 8:23 PM wjf via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> see attachment
> wjf
> wjf_at_[hidden]
>
> <https://wx.mail.qq.com/home/index?t=readmail_businesscard_midpage&nocheck=true&name=wjf&icon=http%3A%2F%2Fthirdqq.qlogo.cn%2Fek_qqapp%2FAQNPOicdlIgbG9Ribmfj8EKjTG2hwBlicwibL4stQmE6UNEQ3eh3aQCoFUzN0k1xGg%2F0&mail=wjf%40zenkee.cn&code=>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
It is extremely unlikely something like this would ever be added to C++.
Such a change would require a lot of motivation, and this paper doesn't
currently provide much motivation.
If the motivation is reusing the name, consider what rust has done with
shadowing:
let x = foo();
let x = x.transform(); // new x shadows old x, can be a new type
There is precedent for this mechanism in C++ now with P2169.
If the motivation is compiler optimization, this is a micro-optimization
and would be harmful as a language feature. Compilers can very easily
identify when objects in a function are dead and reclaim storage and
registers.
If the motivation is ending an object's lifetime as far as the C++ abstract
machine is concerned and calling destructors, just use std::optional:
std::optional<T> thing;
...
thing.reset(); // destroy the object, call the destructor
This is much more simple and straightforward to reason about than the
language feature you're proposing. If you are concerned about the overhead
from the flag std::optional stores to indicate if a value is contained or
not, this is something compilers should be able to optimize with relative
ease, though the overhead would be completely negligible in almost all
cases even if it didn't.
Cheers,
Jeremy
On Tue, Dec 9, 2025 at 8:23 PM wjf via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> see attachment
> wjf
> wjf_at_[hidden]
>
> <https://wx.mail.qq.com/home/index?t=readmail_businesscard_midpage&nocheck=true&name=wjf&icon=http%3A%2F%2Fthirdqq.qlogo.cn%2Fek_qqapp%2FAQNPOicdlIgbG9Ribmfj8EKjTG2hwBlicwibL4stQmE6UNEQ3eh3aQCoFUzN0k1xGg%2F0&mail=wjf%40zenkee.cn&code=>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2025-12-10 16:02:09
