On 10/12/2025 14:06, Jarrad Waterloo via Std-Proposals 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.

If such a "const locking" feature were to be useful, then it must be
maximally efficient. The idea is to be able to add restrictions to how
you can use the identifier in order to catch errors and to make it
easier for the reader to analyse the code - you have an object that must
be modified while you are setting it up, but is unchanging after its
final value is established.

So yes, a const& reference to the original object is likely to be the
choice for non-trivial types, while a simple copy is fine for small and
simple types.

(There would need to be a new syntax to get the desired effect here - if
you write "const auto a = a;" today, the "a" in the initialiser is the
new "const auto" object "a", not the old "a" that is being shadowed.
You are already in the scope of the new identifier while the initialiser
is being evaluated.)

>
> 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] <mailto: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]
> <mailto: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]
> <mailto:std-proposals_at_[hidden]>;
> *CC:* Jarrad Waterloo <descender76_at_[hidden]
> <mailto:descender76_at_[hidden]>>;
> similar
> /3. Const-locking identifiers (redeclaration without undecl) :
>
> It would sometimes be very nice to be able to redeclare a non-const
> variable 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]
> <mailto: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]
> <mailto:std-proposals_at_[hidden]>>
> *Date:* Wed, Dec 10, 2025 12:04 PM
> *To:* "Std-Proposals"<std-proposals_at_[hidden]
> <mailto:std-proposals_at_[hidden]>>;
> *Cc:* "Sebastian Wittmeier"<wittmeier_at_[hidden]
> <mailto: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]
> <mailto: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]
> <mailto:std-proposals_at_[hidden]>>;
> *CC:* Sebastian Wittmeier <wittmeier_at_[hidden]
> <mailto: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]
> <mailto: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]
> <mailto: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]
> <mailto:std-proposals_at_[hidden]>>;
> *CC:* wjf <wjf_at_[hidden] <mailto: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]
> <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
>