Some performance comes from more localized usage which has better cache performance.   For simple types the optimizer can already do it. For complex types that optimization often is not the bottle neck.   If the lifetimes are serial or LIFO it can often directly handled with scopes now instead of a new keyword. If the scopes are overlapping the memory reuse does not work as well.     For the feature to make a performance difference the lifetimes have to be ended prematurely.   Why can't we use local std::optional types? An optimizer could optimize it to be as efficient as direct types?   Or would there be UB cases (which the optimizer would know can't happen), which the optimizer could not take use of with std::optional (because there it would be possible without UB), but with direct types?   -----Ursprüngliche Nachricht----- Von:SD SH <Z5515zwy_at_[hidden]> Gesendet:Mo 15.12.2025 16:08 Betreff:Re: [std-proposals]: Re: [PXXXXR0] Add a New Keyword ‘undecl’ An:std-proposals_at_[hidden]; CC:Sebastian Wittmeier <wittmeier_at_[hidden]>; > But then (if drop or undecl is implemented), the stack would fragment. The restriction of scope we have talked (on Friday) can avoid this problem. By this way, the addresses of objects on stack is known and fixed.   > (if it is just one, there is no performance gain in freeing before the end of the scope) Assume `undecl` ends the object in this example:   ``` alignas(64) std::byte arr[64]; // do something about using it // it usually stays in cache when we used it just now undecl arr; // free the former 'arr' int arr[8]; // then we can overwrite the storage of former 'arr' and access the latter 'arr' without waiting for memory // if the former 'arr' isn't ended when using `undecl`, sometimes the processor has to wait for main memory and gets worse performance.  ``` The fact is that sometimes it brings better performance.