See this paper about alternatives / something similar as VLAs allocated on the stack for C++: https://open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3810.pdf (Stroustrup from 2013) The function_local variables and alloca perhaps have more blockers, if they all stayed non-standard extensions, which have to be solved (or not) first.   -----Ursprüngliche Nachricht----- Von:Mital Ashok via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 01.06.2026 17:12 Betreff:Re: [std-proposals] Function-bound objects with unary operator % An:std-proposals_at_[hidden]; CC:Mital Ashok <mital_at_[hidden]>; On Mon, 1 Jun 2026, 15:53 Sebastian Wittmeier via Std-Proposals, <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: Would it have to be a language feature? Can't you just define an object managing a linked list with alloca? And calling a member function to append a new object? alloca is an extension. This would standardise it (or something similar)  Some bikeshedding: This looks like a storage duration. Maybe it could be done with a specifier like `function_local auto _ = std::async(EntryPoint);`. This also prevents things like `int namespace_scope_variable = ((%...), 0);` from being syntactically possible.  GNU's alloca has an emulation mode using malloc on some platforms where the 'normal' implementation is unavailable. The semantics will need to be defined to be compatible with these sorts of platforms   -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals