yolina

You pretty much need lifetime tracking to make it foolproof.

A quick dirty hack would be to have a static analyzer drop B from the symbol table after it sees std::move and give a warning, but that obviously wont catch other references to it, but maybe it will catch the low hanging fruit.

destructive moves are required to make moves zero cost.

Currently move semantics in C++ requires that A is left in a 'moved from, but valid state' which means that:

1. The compiler must still generate code that calls the destructor.

2. Every destructor need have to have some flag and a test in it like: if(moved_from) // do nothing else { free_resources(); }

(Granted, for some simple types the compiler might inline and removed redundant checks so it ends up with no extra code, but that is not guaranteed)

With destructive moves the compiler can just forget about the object completely, no need to call it, destructurs can be written as normal and only care about the invariants established in the constructor.

Some other language need to step up and rewrite/replace LLVM then, because no language that relies on a ~30 million loc backend written in C++ can ever hope to replace it.

gcc seems to have full C++20, almost everything in 23 and and implemented reflection for 26 which is probably the only thing anyone cares about in 26.

https://en.cppreference.com/w/cpp/compiler_support.html

Funny how gcc seems to be the top dog now, what happened to clang? Thought their codebase was supposed to be easier and more pleasant to work with? Or maybe just more hardcore compiler devs work on gcc?