Date: Wed, 10 Dec 2025 08:06:21 -0500
*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
>
*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
>
Received on 2025-12-10 13:06:36
