Tracking issue for custom_derive feature

[aturon]

Treats #[derive(Anything)] like #[derive_Anything]. Tracking for stabilization.

[eefriedman]

There isn't really much incentive to stabilize this at the moment; this is basically only useful with plugins (and syntex, but the gate doesn't affect that usage).

[nrc]

Is there an RFC for this? I couldn't find one easily.

[eefriedman]

No RFC; see #23137.

[nrc]

Do we know who uses custom_derive? It seems like a horrible hack.

(Thanks for the link @eefriedman)

[pnkfelix]

wow look at the turnaround time on that PR! Proposed, r+'ed, and landed all in one day!

[jimmycuadra]

Two crates that use custom_derive: serde_macros and diesel_codegen.

[eefriedman]

Servo also uses it in a few places, for example https://github.com/servo/heapsize .

[nrc]

Thanks for the info. I think custom derive is something we should support, but not in the current form. I'll have a think about how it fits in to the procedural macro overhaul and write some kind of RFC.

[e-oz]

HOPE WILL NEVER DIE!

Can't use XML/JSON deserialization to structures, but I still hope...

😢

[nrc]

cc #35900

[nrc]

Nominating for deprecation now that we have macros 1.1 custom derive in place.

[nikomatsakis]

@rfcbot fcp close

The general consensus is that this is subsumed by macros 1.1, which offers a more general solution.

[rfcbot]

Team member nikomatsakis has proposed to close this. The next step is review by the rest of the tagged teams:

• @aturon
• @eddyb
• @nikomatsakis
• @nrc
• @pnkfelix

No concerns currently listed.
Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

All relevant subteam members have reviewed. No concerns remain.

[aturon]

🔔 This feature is undergoing its final comment period with disposition to deprecate. 🔔

[rfcbot]

The final comment period is now complete.

[brson]

This is waiting on ultimate removal.

Note that here @SergioBenitez says Rocket needs this feature.

[sfackler]

custom_derive is more powerful in a couple of ways than Macros 1.1; Rocket may be depending on the ability to adjust/remove the struct definition?

[nrc]

I'm in favour of a longer than usual deprecation period. As well as being more powerful, people apparently continue to use old custom derive because they can have a single crate which implements both derives and proc macros, and until we have a more function proc macro 2.0 solution, using new custom derive means having two separate implementations.

[SergioBenitez]

Please see my argument against removal in #37128 (comment). I'm okay with deprecation as long as #38533 remains valid (users don't receive a warning) and I can #[allow(deprecated)] in my codegen crate.

[joshhansen]

I'm confused about the status of this deprecation. The nightly compiler says derive for custom traits will be removed in 1.15, but nightly is now in 1.16. Combined with @SergioBenitez's comments and Rocket's continued dependence on this feature, I'm pretty unsure whether to assume it will continue for the foreseeable future or whether it really is at risk of being removed any time now. Please advise.

[keeperofdakeys]

The deprecation warning was written many months ago, given the above comments the warning should probably be bumped a few versions.

[keeperofdakeys]

So regarding the deprecation warning, what will the next removal target be? 1.17 + 3 = 1.20 perhaps?

[nikomatsakis]

@joshhansen My feeling is that we should remove this and I would definitely not advise writing new code that relies on it. That said, I don't think there is a tremendous hurry to do so; all things being equal I'd prefer not to break rocket, of course. Still, if this feature ever becomes an obstacle to doing something we would want, I would be inclined to remove it ASAP, so migrating is definitely a good idea. I heard something about @jseyfried working with @SergioBenitez to move over to the prototypes of the newer macro system that may be relevant here.

[e-oz]

I feel absolutely confused. You just announced it here: https://blog.rust-lang.org/2017/02/02/Rust-1.15.html
but compiler saying it's deprecated. Please explain me where I'm wrong.

[jseyfried]

@e-oz We just stabilized and announced a different feature (macros 1.1, aka proc_macro) that replaces this feature ("legacy custom derive"). Now that we've have macros 1.1 custom derives, we're deciding when to remove legacy custom derives.

[e-oz]

I have to say it was awful idea to release new feature with exactly same name as old deprecated feature.

[jseyfried]

The name of the new feature was proc_macro, or macros 1.1. Both the old feature and the new feature allow defining and using custom derives.

[jseyfried]

Of course, in retrospect it would have been better to name the old feature something more specific than custom_derive.

[aturon]

I think the complaint was about the release announcement, which said we're stabilizing "custom derive". I agree that this is all a bit confusing, especially for those not following Rust development closely.

[e-oz]

Yes, that's what broke my whole app and gave me work for a couple of next days.

[cramertj]

@SergioBenitez Are you still using this feature?

[SergioBenitez]

@cramertj Yes. With the recent improvements to the proc_macro APIs and a few additional ones, however, I should be able to move Rocket to proc_macro soon.

[fbstj]

@SergioBenitez are you still using this feature?

[SergioBenitez]

Yes. The plan is to migrate away from custom_derive as soon as possible however. Current progress puts us as doing so by next release, or about a month.

[SergioBenitez]

Update: All of Rocket's derives are now implemented as proc-macros and will ship as such in the next official release, which should be within a couple of weeks time.