Yeah, this makes sense. Although all this affine type stuff was also the basis for the C++ move semantics (although the resulting type system isn't affine at all, the mental model is very much that, with deleted copy constructors and all), which predates Rust project by at least a few years. So by the time Rust 1.0 rolled out, it wasn't a new concept at all even in system programming circles.

The actually innovative thing about Rust is how they made object lifetimes into a H-M-esque type system and used this 50 year old algorithm to detect dangling pointers at compile time.

▲

steveklabnik a day ago | parent [-]

To further this, "destructive move" as C++ calls it almost happened, but ended up not. So it almost had it the same way as Rust too.

▲

kmeisthax a day ago | parent [-]

The funny thing is, Rust doesn't quite have a destructive move either. Or, at the very least, it's not exposed to the type system. The Drop trait that tells you if a value of a type T was destroyed can only give you a &mut T to it. There's no type to represent a value you own stored in memory you don't. So we have the funny situation where if you implement Drop, you can't take values out of the thing that got dropped.

	▲	Xirdus 15 hours ago \| parent [-]
		Destructive move is when the move skips destructor. Rust does have that. What it doesn't have is destructive destructuring - you can't skip the destructor when destructuring a struct. Meaning you can only destructure structs that don't impl Drop.