On 24/01/14 04:37, Steven Fackler wrote:
The deriving infrastructure is implemented as a procedural macro (or syntax extension) that's built into the compiler. Historically, _all_ syntax extensions had to be built in but that is no longer the case: https://github.com/mozilla/rust/pull/11151. It's now possible to write something like #[deriving_Drawable] that will implement Drawable for types but you can't currently add new traits to #[deriving(..)] to make something like #[deriving(Clone, Drawable)] work. It would be possible to support that, but it would make #[deriving(..)] "special" in ways that other syntax extensions aren't and it's unclear whether or not that's a good idea.
What exactly is the point of this #[...] syntax, anyway? I'm sure there's a reason, but I *currently* don't see how #[deriving(...)] is better than simply "deriving", like Haskell has. Is maintaining a low keyword count really THAT important, that we have to have ugly #[] wrappers around things? I had thought that #[] represented meta-information, like how to compile/link the file, but if deriving is in there, it's very much involving the language proper, too.
Also, if it's built into the compiler, that makes it special anyway, in my book. However, the derivation feature provides such great functionality, that I'd be very OK with it being a keyword. At least, if it could be extended for other types -- i.e., was made to support deriving_Drawable and so forth.
Finally (and this is more curiosity than suggestion, because it could make the language too dynamic/magic), I wonder what's involved in dropping the "...deriving..." syntax altogether, and automatically deriving functionality for types that implement all the necessary underlying features? It seems like that's what's done for types that fit POD, for example.
-- Lee _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
