On Feb 28, 2014, at 8:10 PM, Kang Seonghoon <[email protected]> wrote:
> 2014-03-01 6:24 GMT+09:00 John Grosen <[email protected]>: >>> On Friday, February 28, 2014 at 11:15 AM, Matthieu Monrocq wrote: >>> >>> Maybe one way of preventing completely un-annotated pieces of data would be >>> a lint that just checks that at least one property (Send, Freeze, ...) or a >>> special annotation denoting their absence has been selected for each >>> public-facing type. By having a #[deriving(...)] "mandatory", it makes it >>> easier for the lint pass to flag un-marked types without even having to >>> reason whether or not the type would qualify. >> >> I generally like this idea; however, I find it a bit strange `deriving` >> would still be implemented as an attribute given its essential nature in the >> language. Haskell, of course, has `deriving` implemented as a first-class >> feature — might Rust be interested in something like that? >> >> Food for thought, at least. > > I second to this. Indeed, we already have similar concerns about > externally-implemented `#[deriving]` (#11813, and somewhat tangently, > #11298), as syntax extensions don't have any clue about paths. I actually rather like the fact that deriving is implemented as an attribute, because it's one less bit of syntax. Right now it's still implemented in the compiler, but this could theoretically eventually move into libstd entirely as a #[macro_registrar]. My main concern with this proposal overall is that types will forget to derive things. I know I almost always forget to derive Eq and Clone for my own structs until I run into an error due to their lack. A lint to warn about missing derivations would mitigate this a lot, although I'm worried that if someone opts out of a single trait by using #[allow(missing_traits)] and a new trait is added to the set, the author will never realize they're missing the new trait. I'm also concerned that if you need to opt out of a single trait from #[deriving(Data)] then you can't use #[deriving(Data)] and must instead list all of the remaining traits. Perhaps for both problems we could introduce the idea of #[deriving(!Send)], which would let me say #[deriving(Data,!Send,!Freeze)] to opt out of those two. I'm also slightly concerned that #[deriving(Data)] gives the impression that there's a trait Data, so maybe that should be lowercased as in #[deriving(data)], or even just #[deriving(builtin)], but this is a lesser concern and somewhat bike-sheddy. -Kevin _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
