I agree that this is a huge headache waiting to happen. It's our own
version of the const-correctness problem.
We do already have a notion of "opt-out" kinds via #[no_freeze] and
#[no_send], so this isn't entirely unprecedented.
It would also be good to know how often one needs custom copy behavior.
>From just looking at rustc:
git grep "impl.*Clone for" | wc -l # 62 manual implementations
(though 11 are just from clone.rs)
git grep "#\[deriving.*Clone" | wc -l # 290 derived implementations
On Thu, Jul 18, 2013 at 7:24 AM, Corey Richardson <[email protected]> wrote:
> So with decopy landed we now have no way to copy things that does not
> require author intervention. And I am ok with this! Clone is much more
> flexible, less magic, etc. I see one problem with this though: we have
> no way to copy things that does not require author intervention.
>
> For example, I ran into this with rustdoc_ng: there is no Clone
> implementation for syntax::ast::struct_def. There's no reason it
> couldn't have one, it's just that it wasn't needed to be cloned, so an
> implementation wasn't added (via #[deriving(Clone)]).
>
> This is a problem. If a library author overlooks something that
> could/should have Clone, users of that library are now with no way to
> copy.
>
> I propose the following:
>
> If a given struct/enum has no Clone implementation, it fulfills the
> requirements of the now-gone Copy kind, and the #[no_clone] attribute
> is not present, #[deriving(Clone)] is automatically applied to it.
>
> I'm not that fond of this sort of magic but it seems to be necessary:
> library authors aren't perfect, and a simple oversight can harmfully
> limiting what can be done with its types.
> _______________________________________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
>
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
