Continuing the discussion from TWiR quote of the week:
Does it bother anyone else that if your code has a custom #[derive()] you either need nightly or you must use a custom build script with additional dependencies (and optionally different features in Cargo.toml) and rename your input file and invoke an additional source-to-source translation?
Maybe it's time to allow compiler plugins on stable? Even if it's just those implementing custom derives? What is the downside of doing that?
Because the compiler's internal interfaces change often (more than once I've seen syntex fail to compile on a new nightly), it would not be able to satisfy the Rust stability promise. Stability as a Deliverable | Rust Blog touches on this a bit.
Thanks for the link.
It says there:
Many major uses of syntax extensions could be replaced with traditional code generation, and the Cargo tool will soon be growing specific support for this use case.
Does that include custom derive implementations? It would sure be great if Cargo could handle the whole "use syntex + rename your file + do source-to-source translation" automatically!
we also see stabilizing syntax extensions as an immediate priority after the 1.0 release.
I see that the document is from 2014/10, that's almost 2 years ago, so apparently that's not what happened in the end 
Also, from the State of Rust Survey 2016, on this topic:
I don’t like having to use a nightly plus a build.rs for parsing json with serde. It needs to be simpler.
and more generally:
the consensus formed around the need to move the ecosystem onto the stable language and away from requiring the nightly builds of the compiler.
I don't know what it takes to get there. I have never written a compiler plugin (and I don't plan to at the moment), so pardon my ignorance. If there must be a version of a compiler plugin tied to a release of stable rust, I think that's acceptable. Is it not possible?
There's a RFC (from 8 days ago) to give us short term relief of this issue: https://github.com/rust-lang/rfcs/pull/1681
perfectly possible, but that means that the burden of providing this plugin is moved to the official compiler. We then can't ever remove the plugin or change it significantly enough to break existing code. That's obviously not a solution.
Hooray for that RFC! 
I look forward to see it implemented!