Further,

These 2 could be made more generally useful with the adoption of pure alias
types.

C++23
Simpler implicit move (FTM
<https://cppreference.com/w/cpp/experimental/feature_test.html#cpp_implicit_move>
)* P2266R3 <https://wg21.link/P2266R3>
There is even an example of this as a special case via reference_wrapper in
this proposal.

C++26
Disallow binding a returned reference to a temporary
<https://cppreference.com/w/cpp/language/reference_initialization.html#Lifetime_of_a_temporary>
P2748R5 <https://wg21.link/P2748R5>

There are already criticisms of function_ref associated with returning
references to temporaries that would be addressed with the more general
solution.


On Wed, Dec 10, 2025 at 8:06 AM Jarrad Waterloo <descender76_at_[hidden]>
wrote:

> *The lifetime is typically bound to an lvalue (it least in this example).*
>
>
>
> *If you reassign a with a non-owning view, the vector is destructed.*
>
> I think the point of what is being asked for is that it wouldn't be.
>
> In like fashion to the person I was responding to.
>
> *const a = a;*
>
> The original non const a would not be ended but the variable a would be
> redefined to be a const & to whatever `a` WAS.
>
> also in the case of removing the current lifetime extension restriction.
>
> The following cases would no longer be immediately dangling.
>
> string_view a = string("");
> span a = vector<>{...};
>
> This would remove an embarrassing form of dangling associated with the
> creation of temporaries.
> This would remove an inconsistency that lifetime extension works on
> reference but not reference like types.
> This allows the programmer to better manage invalidation without having to
> create superfluous aliases that only further enable invalidation.
>
> On Wed, Dec 10, 2025 at 7:53 AM Sebastian Wittmeier via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> The lifetime is typically bound to an lvalue (it least in this example).
>>
>>
>>
>> If you reassign a with a non-owning view, the vector is destructed.
>>
>>
>> -----Ursprüngliche Nachricht-----
>> *Von:* Jarrad Waterloo via Std-Proposals <std-proposals_at_[hidden]>
>> *Gesendet:* Mi 10.12.2025 13:42
>> *Betreff:* Re: [std-proposals] [PXXXXR0] Add a New Keyword `undecl`
>> *An:* std-proposals_at_[hidden];
>> *CC:* Jarrad Waterloo <descender76_at_[hidden]>;
>> similar
>>
>>
>>
>>
>> *3. Const-locking identifiers (redeclaration without undecl) :It would
>> sometimes be very nice to be able to redeclare a non-constvariable as
>> const, to "lock" it against accidental changes:*
>>
>> undeclare without ending lifetime as in I just don't want access to the
>> object anymore
>> This reduces alias count.
>>
>> How about redeclare to a non invalidating view.
>> span a = /*vector*/ a.
>>
>> Prior Work
>>
>> Related
>> P2951R2
>> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2951r2.html> Shadowing
>> is good for safety
>>
>> Also related
>>
>> view only access to object i.e. remove reference only restriction on
>> lifetime extension or in other words change reference to pure alias type
>> P3824R1
>> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3824r1.html> Static
>> storage for braced initializers NBC examples
>> NOTE: This was an NBC on C++26.
>>
>> Concerning guidelines
>> Guidelines have banned C++ features such as dynamic allocation for safety
>> reasons only to allow it in certain circumstances once it has shown to aid
>> safety.
>>
>>
>>
>> On Wed, Dec 10, 2025 at 5:24 AM wjf via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>> I think it's the compiler job to prevent the skip of undecl statement in
>> some branch of program flow. For example the following code is forbidden
>> too.
>>
>> //...
>> {
>> int x = 1;
>> illegal_entry_point:
>> //...
>> }
>>
>> goto illegal_entry_point; //wrong code
>>
>> pdf link: proposals/Add_New_Keyword_undecl.pdf at main ·
>> zenkee/proposals · GitHub
>> <https://github.com/zenkee/proposals/blob/main/Add_New_Keyword_undecl.pdf>
>> ---Original---
>> *From:* "Sebastian Wittmeier via Std-Proposals"<
>> std-proposals_at_[hidden]>
>> *Date:* Wed, Dec 10, 2025 12:04 PM
>> *To:* "Std-Proposals"<std-proposals_at_[hidden]>;
>> *Cc:* "Sebastian Wittmeier"<wittmeier_at_[hidden]>;
>> *Subject:* Re: [std-proposals] [PXXXXR0] Add a New Keyword `undecl`
>>
>> One can do the same without brace levels by using switch case or goto.
>>
>>
>> -----Ursprüngliche Nachricht-----
>> *Von:* Breno Guimarães <brenorg_at_[hidden]>
>> *Gesendet:* Mi 10.12.2025 02:35
>> *Betreff:* Re: [std-proposals] [PXXXXR0] Add a New Keyword `undecl`
>> *An:* Std-Proposals <std-proposals_at_[hidden]>;
>> *CC:* Sebastian Wittmeier <wittmeier_at_[hidden]>;
>> The paper says that undecl can only be called in the same brace level as
>> the declaration. So I guess this example isn't valid.
>>
>> Em ter., 9 de dez. de 2025, 22:29, Sebastian Wittmeier via Std-Proposals <
>> std-proposals_at_[hidden]> escreveu:
>>
>> undeclaring a variable is the same as relocating from a variable to
>> nothingness (or to somewhere else).
>>
>>
>>
>> A variable, which was relocated from, may also not be used any longer
>> afterwards.
>>
>>
>>
>>
>>
>> One detail may be the difference between position in the program (source
>> code line within the block) and program flow.
>>
>>
>>
>> int a = -1;
>>
>> for (int i = 0; i < 10; i++) {
>>
>> if (i == 5)
>>
>> a++; // can a be used here?
>>
>> if (i == 4)
>>
>> undecl a;
>>
>> if (i == 5)
>>
>> a++; // and here?
>>
>> }
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> *Von:* wjf via Std-Proposals <std-proposals_at_[hidden]>
>> *Gesendet:* Mi 10.12.2025 02:23
>> *Betreff:* [std-proposals] [PXXXXR0] Add a New Keyword `undecl`
>> *Anlage:* Add_New_Keyword_undecl.pdf
>> *An:* std-proposals <std-proposals_at_[hidden]>;
>> *CC:* wjf <wjf_at_[hidden]>;
>> see attachment proposals/Add_New_Keyword_undecl.pdf at main ·
>> zenkee/proposals · GitHub
>> <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=>
>> 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_[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
>>
>> --
>> 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
>>
>> --
>> 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
>>
>