I don’t think this is particularly insightful, as move semantics and r-values are higher level language semantics, nothing more and nothing less.

Rust’s borrow checker doesn’t actually borrow anything either, it’s operating on a similar level of abstraction.

▲

masklinn 13 hours ago | parent [-]

> Rust’s borrow checker doesn’t actually borrow anything either

Why would it? It's called the borrow checker, not the borrower. So it checks that your borrows are valid.

std::move looks and feels like a function, but it doesn't do what it says, it makes objects movable but does never moves them (that's up to whatever is using the value afterwards). If you want something similar in Rust, Pin is a much better candidate.

▲

vouwfietsman 11 hours ago | parent [-]

Sure, but from the perspective of the code that has the move() its good to assume the value is moved at that call, which I guess was the intention of picking the name.

	▲	masklinn 5 hours ago \| parent \| next [-]
		Usually yes, however because that's not for some resource types it can lead to less than ideal behaviour e.g. if your RAII resource is something which will get corrupted if there are two handles to it (some sort of odd hardware resource), you std::move() the object into a callee, assume it is moved and released, so you acquire a new resource, and turns out the callee did not move it and now you have two of them.
	▲	dathinab 5 hours ago \| parent \| prev [-]
		yes std::move tells the devs and the compiler that you _intend_ the value to be moved sadly that isn't reflected well in it's implementation as it will "silently" degrade even if it isn't a "move" (1) A `std::move` which fails to compile if it can't be a move(1) it would not have this issues. But it has other issues, mainly wrt. library design especially related to templates/generics, which probably(?) need a `std::move` which works like the current one. I think someone else in this comment section already argued that one issue with modern C++ is too much focusing on the complicated/template/const library design by experts case compared to the "day to day" usage by non experts. (1): There is a bit of gray area in what in rust would be Copy types, for simplicity we can ignore them in this hypothetical argument about an alternative std::move design.