std::vector ======== For a std::vector specifically, we would probably reassign an empty vector or use .clear() together with shrink_to_fit()?   The size of the vector itself (without its storage) should not be so relevant for performance? In very tight embedded situations, vector would probably not be used at all.   std::array ======= It would be an advantage for local large objects, e.g. large std::array. But then (if drop or undecl is implemented), the stack would fragment.   stack vs. heap =========== And if it is to be expected that more than one variable may be allocated and deallocated (if it is just one, there is no performance gain in freeing before the end of the scope), wouldn't typically a heap (or manual memory management, in the simplest case with union or std::variant) be the option of choice?     -----Ursprüngliche Nachricht----- Von:Simon Schröder via Std-Proposals <std-proposals_at_[hidden]> Gesendet:So 14.12.2025 08:43 Betreff:Re: [std-proposals] 回复: 回复: 回复: 回复: [PXXXXR0] Add a New Keyword ‘undecl’ An:std-proposals_at_[hidden]; CC:Simon Schröder <dr.simon.schroeder_at_[hidden]>; > On Dec 13, 2025, at 1:33 PM, Marcin Jaczewski via Std-Proposals <std-proposals_at_[hidden]> wrote: > > btw > > how this will work with `goto`? > > Its legal to go back in same scope and then we can have situation like: > > ``` > std::string x = "1234567890"; > TAG: > x += "aaaa"; > undecl x; > if (x.size() < 100) goto TAG; > ``` > > without `undecl` this is valid code. Well, after the undecl the if-statement wouldn’t work. Let’s assume that the undecl is also part of the if instead. It was last suggested that undecl only ends the visibility of the variable but not its lifetime. Then the goto would not be problematic as the underlying object would still be there. It would only mean that after this line x cannot be accessed anymore. I would say that both ending the visibility of a variable early and ending the lifetime of an object early could be interesting (but separate). For ending the lifetime of objects early I think of Rust’s drop (explicitly ending the lifetime early; could be done with std::optional) and Mojo. Mojo will automatically end the lifetime of an object after its last use instead of at the end of the scope. They claim that this improves performance (at least we would have more memory available if we free vectors early). If this claim is true we would want to have the better performance in C++ as well. These two features (visibility and lifetime) seem to be orthogonal. But sometimes it would be nice to do both at the same time which would require suitable keywords to allow ending both visibility and lifetime on the same line. > > sob., 13 gru 2025 o 05:03 SD SH via Std-Proposals > <std-proposals_at_[hidden]> napisał(a): >> >>> Moving has to keep the object in a valid state. >> >> The destructor will be called same as origin. >> >>> Calling the destructor would probably lead to double-destruction. >> >> Moving and destructing are additional operations. This feature not be used to do these things. >> Calling destructor leads double-destruction. I hope there is a way to end objects early and explicitly if we need, but using obj.~T() or std::destruct_at(&obj) may be incorrect. >> >> It isn't directly related to the feature we are talking, sorry that I talking far ahead. >> >> ________________________________ >> 发件人: Std-Proposals <std-proposals-bounces_at_[hidden]> 代表 Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> >> 发送时间: 2025年12月13日 10:47 >> 收件人: std-proposals_at_[hidden] <std-proposals_at_[hidden]> >> 抄送: Sebastian Wittmeier <wittmeier_at_[hidden]> >> 主题: Re: [std-proposals] 回复: 回复: 回复: [PXXXXR0] Add a New Keyword ‘undecl’ >> >> >> The cleanest approach is to relocate (trivial relocatability was delayed for after C++26) the object into nothing. >> >> >> >> That would probably just destruct it, but the compiler would know, not to destruct it a second time. >> >> >> >> Moving has to keep the object in a valid state. >> >> >> >> Calling the destructor would probably lead to double-destruction. >> >> >> -----Ursprüngliche Nachricht----- >> Von: SD SH <Z5515zwy_at_[hidden]> >> Gesendet: Sa 13.12.2025 02:20 >> Betreff: Re: [std-proposals] 回复: 回复: 回复: [PXXXXR0] Add a New Keyword ‘undecl’ >> An: std-proposals_at_[hidden]; >> CC: Sebastian Wittmeier <wittmeier_at_[hidden]>; >> Thinking of more cases, we can move the object, call the destructor, use std::destroy_at or just do nothing until it end, so changing lifetimes is not necessary and it will introduce trouble in managing a object. >> >> -- >> 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