Right, we already have opt-out, and having elementary functions like Clone predefined also has precedence in other languages. See java and the overwritable clone() method on Object for example. Am 18.07.2013 15:36 schrieb "Benjamin Striegel" <[email protected]>:
> 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 > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
