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 < [email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
