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@lists.isocpp.org>
Gesendet: Fr 26.07.2024 13:11
Betreff: [std-proposals] Attribute [[destructive]]
An: std-proposals@lists.isocpp.org;
CC: Robin Savonen Söderholm <robinsavonensoderholm@gmail.com>;

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@lists.isocpp.org
 https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals