Tracking Issue for RFC 3107: derive_default_enum

[pnkfelix]

This is a tracking issue for the RFC 3107: "#[derive(Default)] on enums with a #[default] attribute" (rust-lang/rfcs#3107).
The feature gate for the issue is #![feature(derive_default_enum)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring
  instructions?)
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (done by Stabilize derive_default_enum #94457) (see instructions on rustc-dev-guide)

Unresolved Questions

None so far

Implementation history

[ibraheemdev]

Implementation PR was already created: #86735

[jhpratt]

Implementation has landed.

[jhpratt]

Actually, this is a duplicate of #86985. As the tracking issue in code links to this, I'll close that even though it was opened first.

Unresolved question for the record:

• Should multiple #[default] attributes on the same variant be denied?

[janriemer]

Unresolved question for the record:

* Should multiple `#[default]` attributes on the same variant be denied?

@jhpratt @pnkfelix I've seen this in the Unresolved Questions section of the duplicate #86985, but it doesn't show up in this issue (only after three comments when @jhpratt points it out). I think, we should put it here in the Unresolved Questions section as well, so people see it at first glance and don't have to scroll three comments to see it (and therefore don't miss it that easily).
Thank you for considering this.

[jhpratt]

With #88681 being merged, I'm inclined to resolve the question of multiple #[default] attributes in favor of prohibiting them. This is the current behavior. There's not really a reason to have it warn instead of outright error in my opinion, and it could conflict if #[default = val] is permitted in the future.

[fbstj]

https://github.com/rust-lang/rust/blob/master/src/test/ui/feature-gates/feature-gate-derive_default_enum.stderr still points at #86735. this file was the most "useful" result when I searched the feature gate on the repository/

[jhpratt]

To match the actual implementation, the RFC text was updated to use the derive_default_enum feature name. If someone could update the title and text of this issue that would be great.

[jhpratt]

How do people feel about stabilizing this? There was a minor concern from @Mark-Simulacrum in #92366, but that's a diagnostic that can be changed at any time. The implementation is straightforward, tested, used in rustc, and has remained unchanged for ~7 months.

[jhpratt]

Stabilization PR: #94457

[jhpratt]

Stabilization report

Summary

An attribute #[default], usable on enum unit variants, is introduced thereby allowing some enums to work with #[derive(Default)].

#[derive(Default)]
enum Padding {
    Space,
    Zero,
    #[default]
    None,
}

assert_eq!(Padding::default(), Padding::None);

The #[default] and #[non_exhaustive] attributes may not be used on the same variant.

Test cases

• The feature gate itself is tested in feature-gate-deriving_default_enum.rs.
• The basic, successful case is tested in deriving-default-enum.rs.
• A number of edge cases are tested in macros-nonfatal-errors.rs:
  • #[default] on structs
  • #[default] on the enum as a whole
  • #[default] on the type (not the variant)
  • no declared default
  • multiple declared defaults
  • #[default] with a value
  • multiple #[default] attributes
  • #[default] on non-unit variant
  • #[default] on #[non_exhaustive] variant

Documentation

PR to update the reference will be made shortly.

Unresolved questions

There was one: whether multiple #[default] attributes should be accepted on a single variant (with no semantic effect). This was resolved in #92366 because #88681 implemented a similar check compiler-wide. Multiple #[default] attributes are not permitted.

[joshtriplett]

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @cramertj
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm

Concerns:

• I-think-this-is-libs-api (Tracking Issue for RFC 3107: derive_default_enum #87517 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.

[nikomatsakis]

No matter whose jurisdiction it is, this seems really useful, +1 from me. I would like a few more knobs on our derives.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[clarfonthey]

So, here's an interesting thing that I didn't see brought up, that I don't think should block stabilisation of the base feature, but should probably be mentioned.

What about unions?

#[derive(Default)]
pub union Thing {
    #[default]
    one: One,
    two: Two,
    three: Three,
}

We could easily make this create the below implementation:

impl Default for Thing {
    fn default() -> Thing {
        Thing { one: One::default() }
    }
}

[jhpratt]

That seems like a reasonable future possibility.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[JohnTitor]

Triage: the stabilization PR (#94457) has landed 🎉 Closing as done.

[ilyvion]

I don't know if this is the right place to ask, but why is it that

the #[default] attribute may only be used on unit enum variants

? I feel like a more natural behavior would be to behave like #[derive(Default)] behaves in every other context; which is that

#[derive(Default)]
struct Foo<T>(T);

will only be Default when T: Default and its value will be Foo(T::default()). That is to say,

#[derive(Default)]
pub enum Error<T> {
    #[default]
    Message(T),
    Other,
}

would only be Default when T: Default and its value would be Error::Message(T::default()).

[m-ou-se]

@alexschrod How about these cases?

#[derive(Default)]
pub enum Either<A, B> {
    #[default]
    One(A),
    Two(B),
}

Does that require only A: Default? Or also B: Default?

How about this?

#[derive(Default)]
pub enum MaybeOption<T> {
    #[default]
    Yes(Option<T>),
    No,
}

Does that require T: Default or Option<T>: Default?

[ilyvion]

It makes sense that for a struct all the generic types must be Default (at least given its current, somewhat unfortunate behavior, as I'll discuss farther down), but for an enum, it only makes sense to require the one(s) involved in the #[default] value to be Default. Which makes the answer obviously A only, in the first case. For the second case, the "ideal" answer is Option<T>, but since #[derive(Default)] seems to not have a lot of existing finesse with structs (struct Foo<T>(Option<T>) will end up with a "bad" T: Default bound, e.g.) one could carry that unfortunate legacy on with enums too, for the sake of feature parity.

[scottmcm]

but why is it that

Because derive(Debug) works totally differently from ever other derive when generic parameters are involved. (This was discussed in the FCP a bunch.)

Since it's not using the "we put the bound on all the generic parameters" approach, this is a great future-proofing until it's decided whether it should ever do anything else.

Maybe we'll one day get "perfect derive" (https://smallcultfollowing.com/babysteps//blog/2022/04/12/implied-bounds-and-perfect-derive/) that will give a different way to do this for everything, and that's when the rules will change.

[ilyvion]

Thanks for the explanation, @scottmcm, it makes sense to me now that this first version is intentionally conservative with regard to a less problematic possible future improvement.