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@lists.isocpp.org> 代表 wjf via Std-Proposals <std-proposals@lists.isocpp.org>
发送时间: 2025年12月11日 9:11
收件人: std-proposals <std-proposals@lists.isocpp.org>
抄送: wjf <wjf@zenkee.cn>
主题: 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
wjf
wjf@zenkee.cn


原始邮件
发件人：Jeremy Rifkin via Std-Proposals <std-proposals@lists.isocpp.org>
发件时间：2025年12月11日 00:01
收件人：std-proposals <std-proposals@lists.isocpp.org>
抄送：Jeremy Rifkin <jeremy@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@lists.isocpp.org> wrote:
see attachment

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals