there is something to clarify it:
- prematurely ending the lifetime: yes (when = void or resuing the name)
- not using the identifier anymore: yes (only between = void and resuing the name)
________________________________
发件人: Std-Proposals <std-proposals-bounces_at_[hidden]> 代表 Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>
发送时间: 2025年12月12日 22:13
收件人: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
抄送: Sebastian Wittmeier <wittmeier_at_[hidden]>
主题: Re: [std-proposals] 回复: [PXXXXR0] Add a New Keyword ‘undecl’


Hi Himers,



so



 - reusing the name / shadowing: yes

 - prematurely ending the lifetime: yes (only when reusing the name)

 - drop 'privileges' to only r/o = const access: yes

 - not using the identifier anymore: yes (only with ending lifetime)

 - where can it be done: only at static locations in the program flow (no conditionals)



The only at same level rule, does not make much sense, as



{

   int a;

   float b;

}



is the same as (in regards to lifetime)



{

   int a;

   {

      float b;

   }

}


-----Ursprüngliche Nachricht-----
Von: SD SH via Std-Proposals <std-proposals_at_[hidden]>
Gesendet: Fr 12.12.2025 15:02
Betreff: [std-proposals] 回复: [PXXXXR0] Add a New Keyword ‘undecl’
An: std-proposals_at_[hidden];
CC: SD SH <Z5515zwy_at_[hidden]>;
Hi.

```
void foo() {
    float a = 1.1f;

    using a = int { a }; // 'a' will be a identifier of int, from "float a" (equals "int a { 1.1f };" there), then end lifeline of "float a"
    std::cout << a; // std::cout.operator <<(int), output: 1
    using a = int { 1 }; // OK, equals "a = int { 1 };" or "a = 1;"
    a = 2; // OK
_former:

    using a = static; // not allowed
    using a = thread_local; // not allowed
    static int b = 0; // or thread_local int b
    using b = const; // it tells compiler that we won't change it in the future, or cause undefined bahavior
    int *c = &b;
    using *c = const; // 'c' will be const int*

    if(a == 2) {
        using a = float { 3.0 }; // error, because it might ends the lifeline in advance
    }
    try {
        using a = const int { a }; // OK
    }
    catch(std::runtime_error) {
        using a = const int { a }; // now allowed
    }

    goto _latter; // OK
    using a = const; // add const
    a = 4; // error: a is const int
_safe_former:
_latter:
    a = 5; // error: a is const int
    goto _former; // undefined behavior, because the lifeline of "int a" has ended.
    goto _safe_former; // OK, it just jump back to _safe_former, "const int a" is still alive
    using a = void; // end lifeline of "int a" and do nothing
    a = 6; // error: identifier 'a' not found
}
```

Are you describing the behaviors like above? Using a existing keyword is better, and quite concise.

simple syntax:
    "using" <identifier> "=" <expression | type-qualifier>
detail information:
    the statement and the redecling must in same scope, or the redecling in a try block
    the lifeline of identifier must in a single function
    "using" <...> "=" <type> will be matched as type-alias

Himers

________________________________
发件人: Std-Proposals <std-proposals-bounces_at_[hidden]> 代表 wjf via Std-Proposals <std-proposals_at_[hidden]>
发送时间: 2025年12月11日 9:11
收件人: std-proposals <std-proposals_at_lists.isocpp.org>
抄送: wjf <wjf_at_[hidden]>
主题: Re: [std-proposals] [PXXXXR0] Add a New Keyword ‘undecl’

The motivation of this proposal is to make this language more logically consistent and complete. As stated in the PDF, programmers can start the lifetime of a variable wherever they wish within a function, but cannot terminate it at the point they desire. This constitutes a form of incompleteness. And in practice, I use the work arround method a lot to use temporily variables in my own code. But I think they are ugly.

pdf link: https://github.com/zenkee/proposals/blob/main/Add_New_Keyword_undecl.pdf

<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=>
[http://thirdqq.qlogo.cn/ek_qqapp/AQNPOicdlIgbG9Ribmfj8EKjTG2hwBlicwibL4stQmE6UNEQ3eh3aQCoFUzN0k1xGg/0]
wjf
wjf_at_[hidden]


原始邮件
________________________________
发件人：Jeremy Rifkin via Std-Proposals <std-proposals_at_[hidden]>
发件时间：2025年12月11日 00:01
收件人：std-proposals <std-proposals_at_[hidden]>
抄送：Jeremy Rifkin <jeremy_at_rifkin.dev>
主题：Re: [std-proposals] [PXXXXR0] Add a New Keyword `undecl`

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]<mailto:std-proposals_at_[hidden]>> wrote:
see attachment

[http://thirdqq.qlogo.cn/ek_qqapp/AQNPOicdlIgbG9Ribmfj8EKjTG2hwBlicwibL4stQmE6UNEQ3eh3aQCoFUzN0k1xGg/0]<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=>
wjf<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=>
wjf_at_zenkee.cn<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]<mailto: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