I am not saying it is a wrong feature. It can make sense in some situations. But even providing such a feature can come with a cost, if it is more difficult to reason and understand the code.   One can compare it (from its effects) to several return statements within a function. This is possible today, but many organizations are not happy about it, and forbid it with coding guidelines. Others think, that some code can be better expressed with that feature.   If this is not your main intent, I would just focus on the releasing the identifier and not mess with lifetime at the same time; or mention that as option in your proposal paper.   By itself, the change in lifetime could very well be more controversial than the release and reuse of the identifier.   -----Ursprüngliche Nachricht----- Von:SD SH via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 12.12.2025 20:44 Betreff:Re: [std-proposals] 回复: 回复: 回复: [PXXXXR0] Add a New Keyword ‘undecl’ An:std-proposals_at_[hidden]; CC:SD SH <Z5515zwy_at_[hidden]>; You are right.   The usage I thought is using a new object instead of the original object, and tell compiler we don't use the current object anymore. It seems that we have different purpose on this feature. As for the immediate closing, it is indeed unreasonable.   Follow your opinion, the feature might only unbind the object and identifier and then the identifier be released, right? -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals