3 ms·
Yes 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
by School-Cotton 1y ago
Yes 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.