[rust-dev] Deriving keyword

Lee Braiden leebraid at gmail.com
Fri Jan 24 00:28:07 PST 2014

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.


More information about the Rust-dev mailing list