RFC: Allow external #[deriving(...)] implementations

[rust-highfive]

Issue by sfackler
Sunday Jan 26, 2014 at 06:47 GMT

For earlier discussion, see rust-lang/rust#11813

This issue was labelled with: A-syntaxext in the Rust repository

---

Background

Now that #11151 has landed, third-party code can define syntax extensions just as the compiler does - with the exception of adding new types to #[deriving(..)]. It is possible to write an extension that does the same thing as #[deriving(..)] does, but it has to be implemented as #[deriving_MyTrait] instead of #[deriving(MyTrait)]. This unfortunate, especially when a user wants to derive multiple first- and third-party traits:

#[deriving(Clone, Eq, Ord)]
#[deriving_Foo]
#[deriving_Bar]
#[deriving_Baz]
pub struct Blah {
    ...
}

The repetition of multiple #[deriving_Foo]s was the driving force for the creation of #[deriving(..)] in the first place!

The Proposal

Change the signature of the macro registration function to this:

pub type MacroCrateRegistrationFun =
    fn(macro_callback: |Name, SyntaxExtension|,
       deriving_callback: |~str, DerivingExtension|);

#[deriving(..)] types will be registered by the extension infrastructure just like other syntax extensions are.

This does have a (potentially) large downside: the extension infrastructure will have to have special knowledge of #[deriving(..)] to keep track of the registered extensions. I think it's probably worth it, and there are already some other "special" extensions like trace_macros!. What does everyone else think?

[Manishearth]

Alternate proposal: http://discuss.rust-lang.org/t/pre-rfc-auto-derive-for-generating-deriving-decorators/709/3

[alexcrichton]

I believe this has since been implemented, so closing.