> Rust disables implicit copying for structs with destructors
"Disabling" is maybe not the right way to think about it. Rust only has "implicit copying" for Copy types, so you have to at the very least #[derive(Copy,Clone)] to get this, it's true that you can't (and therefore neither can a derive macro) impl Copy on types which implement Drop and that's on purpose but you're making a concrete decision here - the answer Rust knows is never correct is something you'd have to ask for specifically, so when you ask it can say "No" and explain why.
Lots of similar behaviour in C++ is silent. Why isn't my Doodad behaving the way I expected? I didn't need to ask for it to have the behaviour I expected but the compiler concludes it can't have that behaviour, so, it doesn't, and there's nowhere for a diagnostic which says "Um, no a Doodad doesn't work like that, and here's why!"
Diagnostics are hard and C++ under-values the importance of good diagnostics. Rust recently landed work so libraries can provide improved diagnostics when you try to call them with inappropriate parameters. For example now if you try to collect() an iterator into a slice, the compiler notices that slice doesn't implement FromIterator and it asks FromIterator to explain why this can't work, whereupon FromIterator notices you were trying to use a slice and emits a diagnostic for this particular situation - if you'd tried to collect into an array it explains how you'd actually do that, since it's tricky - the slice is impossible since it's not an owning type, you need to collect into a container.
"Disabling" is maybe not the right way to think about it. Rust only has "implicit copying" for Copy types, so you have to at the very least #[derive(Copy,Clone)] to get this, it's true that you can't (and therefore neither can a derive macro) impl Copy on types which implement Drop and that's on purpose but you're making a concrete decision here - the answer Rust knows is never correct is something you'd have to ask for specifically, so when you ask it can say "No" and explain why.
Lots of similar behaviour in C++ is silent. Why isn't my Doodad behaving the way I expected? I didn't need to ask for it to have the behaviour I expected but the compiler concludes it can't have that behaviour, so, it doesn't, and there's nowhere for a diagnostic which says "Um, no a Doodad doesn't work like that, and here's why!"
Diagnostics are hard and C++ under-values the importance of good diagnostics. Rust recently landed work so libraries can provide improved diagnostics when you try to call them with inappropriate parameters. For example now if you try to collect() an iterator into a slice, the compiler notices that slice doesn't implement FromIterator and it asks FromIterator to explain why this can't work, whereupon FromIterator notices you were trying to use a slice and emits a diagnostic for this particular situation - if you'd tried to collect into an array it explains how you'd actually do that, since it's tricky - the slice is impossible since it's not an owning type, you need to collect into a container.