Hacker News Reader

Comment by aapoalas | Hacker News Reader

Auto-deriving Copy would also mean that there needs to be an escape-hatch: eg. Vec would auto-derive Copy.

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() {}

Oh, good point yeah; I wasn't thinking of Drop clashing with Copy, but just about the fields that make up a `Vec`.

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

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

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

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

const T is Copy, actually.

https://doc.rust-lang.org/std/primitive.pointer.html#impl-Co...

Reply on news.ycombinator.com