[rust-dev] Deriving keyword

Steven Fackler sfackler at gmail.com
Thu Jan 23 20:37:23 PST 2014


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.

Steven Fackler


On Thu, Jan 23, 2014 at 8:32 PM, benjamin adamson <
adamson.benjamin at gmail.com> wrote:

> Question, what constitutes whether a 'trait' is applicable for
> implementation by the #deriving() attribute?
>
> According to the language specification on master:
> http://static.rust-lang.org/doc/master/rust.html#deriving
>
> There exists a static list. I found myself interested in the idea of using
> the deriving attribute to derive a simple drawable implementation:
>
>
> https://github.com/JeremyLetang/rust-sfml/blob/master/src/rsfml/traits/drawable.rs
>
> but then looked up the attribute in the rust manual, and noticed that
> there is a static list of what I will call 'traits that support the
> deriving attribute'. Why the restriction? Is there some prior reading on
> this? Is there any plan on letting libraries define more types that can be
> 'derivable'?
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140123/e0bd8e0b/attachment.html>


More information about the Rust-dev mailing list