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.
I find that this applies equally to other traits like `DeepClone` and `Eq` so solving it for one more commonly used trait won't fix the issue. Almost every type should also have a `DeepClone` implementation and most should also have `Eq` *and* `TotalEq`. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
