Not being allowed to use a variable anymore after a call sounds like relocating a variable instead of just containing a valid object in a move-from state.   There are several proposals in flight about relocating. Perhaps you could see, if you're use case is covered or how this feature would integrate with the relocation mechanism.       -----Ursprüngliche Nachricht----- Von:Robin Savonen Söderholm via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 26.07.2024 13:11 Betreff:[std-proposals] Attribute [[destructive]] An:std-proposals_at_[hidden]; CC:Robin Savonen Söderholm <robinsavonensoderholm_at_[hidden]>; I got the idea to make a type to simplify forwarding, e.g. by doing something like: ```c++ template <typename T> class as_forward {   T&& val_;  public:   constexpr as_forward(...) ...   [[destructive]] constexpr T&& operator*() { return std::forward<T>(val_); } }; ``` In which the `[[destructive]]`-attribute would be a marker for the compiler that once this function is called, it should be deemed the end-of-scope for the object (-s) it is called on and any usage of the variable afterwards should make the program ill-formed (or at least, give a compiler warning that can be made an error). However, I realize as I am writing this email that a similar function would be of use for function parameters as well, so if the attribute can be applied to parameters, we could have a `std::move_d(...)` that behaves similarly.  It could help library writers to produce even safer C++-code, and would open up for forwarding-types similar to the prototype above.  I have never written a proposal before, but would this be a library or core-language proposal? // With best regards, Robin Savonen Söderholm -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals