[rust-dev] Deriving keyword
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