4 ms·

> “just ban simple automatic storage duration structure copying” is a terrible usability and horrific ergonomics decision to make This sounds like a great idea

by pornel 2y ago

> “just ban simple automatic storage duration structure copying” is a terrible usability and horrific ergonomics decision to make This sounds like a great idea to me! Rust disables implicit copying for structs with destructors, and together with move-by-default, it works really well. Unlike PoD structs, you don't need to heap allocate them to ensure their uniqueness. Unlike copy constructors, you don't need to worry about implicit copies. Unlike C++ move, there's no moved-from junk value left behind.

meinersbur 2y ago
IMHO it would still be a useful feature, just one that is not strictly needed. You are not able to to pass around such structs, but neither is that possible with the suggested `defer` statement. The only advantage of `defer` is that the destructor code is inline, rather than in a separate destructor function. But you could gain reusability of headers to be also used in C++, not needing to reinvent the wheel with new issues (e.g. variable lifetime), and a whole lot of existing experience with RAII.
tialaramex 2y ago
> 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.

by pornel 2y ago

meinersbur 2y ago

IMHO it would still be a useful feature, just one that is not strictly needed. You are not able to to pass around such structs, but neither is that possible with the suggested `defer` statement. The only advantage of `defer` is that the destructor code is inline, rather than in a separate destructor function. But you could gain reusability of headers to be also used in C++, not needing to reinvent the wheel with new issues (e.g. variable lifetime), and a whole lot of existing experience with RAII.

tialaramex 2y ago

> 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.