3 ms·
Auto-deriving Copy would also mean that there needs to be an escape-hatch: eg. Vec would auto-derive Copy.
by aapoalas 1y ago
Auto-deriving Copy would also mean that there needs to be an escape-hatch: eg. Vec would auto-derive Copy.
- School-Cotton 1y agoYes you would need an escape hatch, but your example is wrong. Vec can't be Copy, because it has a destructor. This program fails to compile: #[derive(Clone, Copy)] struct S; impl Drop for S { fn drop(&mut self) {} } fn main() {}
- aapoalas 1y agoOh, good point yeah; I wasn't thinking of Drop clashing with Copy, but just about the fields that make up a `Vec`.
- aapoalas 1y agoActually; I'm not sure I'm wrong. If Copy was automatically derived based on fields of a struct (without the user explicitly asking for it with `#[derive(Copy)]` that is, as the parent comment suggested the OP is asking for), then your example S and the std Vec would both automatically derive Copy. Then, implementing Drop on them would become a compile error that you would have to silence by using the escape hatch to "un-derive" Copy from S/Vec. So, whenever you wanted to implement Drop you'd need to engage the escape hatch.
- School-Cotton 1y agoWhat I suggested OP was asking for was: > all types that _can_ implement `Copy` should do so automatically unless you opt out , which was explicitly intended to exclude types with destructors, not > types should auto-derive `Copy` based purely on an analysis of their fields.
- tonyedgecombe 1y agoSo if you have some struct that you use extensively through an application and you need to extend it by adding a vector you are stuck because the change would need to touch so much code.
- sapiogram 1y agoCopy is already banned for any type that directly or indirectly contains a non-Copy type, and Vec contains a `*const T`, which is not Copy.
- School-Cotton 1y agoconst T is Copy, actually. https://doc.rust-lang.org/std/primitive.pointer.html#impl-Copy-for-*const+T https://doc.rust-lang.org/std/primitive.pointer.html#impl-Co...