Tracking issue for RFC 3681: Default field values

[estebank]

This is a tracking issue for the RFC "3681" (rust-lang/rfcs#3681).
The feature gate for the issue is #![feature(default_field_values)].

Allow struct definitions to provide default values for individual fields and
thereby allowing those to be omitted from initializers. When deriving Default,
the provided values will then be used. For example:

#[derive(Default)]
struct Pet {
    name: Option<String>, // impl Default for Pet will use Default::default() for name
    age: i128 = 42, // impl Default for Pet will use the literal 42 for age
}

let valid = Pet { name: None, .. };
assert_eq!(valid.age, 42);
let default = Pet::default();
assert_eq!(default.age, 42);

let invalid = Pet { .. };

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.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

• Implement the RFC (cc @rust-lang/compiler)
  • Parse the new syntax
  • Support #[derive(Default)] expansion of structs with default field values
  • Support #[derive(Default)] expansion of struct variants where every field has a default
  • Restrict #[non_exhaustive] on items with default field values
  • Restrict defaults on tuple struct and tuple variants
  • Define visibility of defaulted field values on value construction (S { .. } is allowed if a in struct S { a: () } is not visible?)
  • Restrict S { .. } when S has no fields with default values
  • Lint against explicit impl Default when #[derive(Default)] would be ok
    • Additional lints for iffy cases (maybe belongs in clippy?)
• Adjust documentation (see instructions on rustc-dev-guide)
  • Add unstable book entry
  • Add to the Reference
  • Mention in The Book
  • Add example to Rust By Example
• Formatting for new syntax has been added to the Style Guide (nightly-style-procedure)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• What is the right interaction wrt. #[non_exhaustive]? Made mutually exclusive.
• Customization of behavior wrt. visibility rules (allow user to specify that value can be constructed with .. covering defaulted field that otherwise is not accessible) Following RFC: struct can't be constructed with .. if it covers a private field.
• Allowing .. on types with no default fields, particularly in unit structs?* Disallowed, can be added later if we find a reason to support that.
• Allowing the use of field_name: _ to specify the use of the default for that specific field?* Let's not try that, particularly in the face of ~const Default allowing for field_name: Default::default() and field_name: default()
• Tuple structs and tuple variant support* Let file a subsequent RFC for this.
• Integration with (potential, at this time) structural records*
• Integration with (potential, at this time) literal type inference (_ { .. })*
• Exposing default field values as individual consts in the syntax? (I lean towards "unneeded") If an API needs the default to be expressed, it can be an associated const and use field_name: Self::CONST_DEFAULT, making it accessible
• Expand support to non-const values? (Personal position is that we shouldn't do that, particularly seeing how powerful const eval is becoming.)

* Decision not needed for stabilization of this feature, can be follow up work.

Implementation history

• Initial implementation:
  Introduce default_field_values feature #129514
• Minor test add:
  Exercise const trait interaction with default fields #134136
• Make sure to use normalized ty for unevaluated const in default struct value [ICE fix]:
  Make sure to use normalized ty for unevaluated const in default struct value #134314
• Lints for Default impls that could diverge against default field values:
  Implement default_could_be_derived and default_overrides_default_fields lints #134441
  • Only lint for "manual impl Default without using .. for all default fields":
    Implement default_overrides_default_fields lint #134737
  • 1st Experiment:
    Lint against manual impl Default that could have been derived #134175
  • Reuse logic from Implement default_could_be_derived and default_overrides_default_fields lints #134441 that looks at the Default::default() body in existing derivable_impls clippy lint:
    Use MIR body to identify more "default equivalent" calls for derivable_impls rust-clippy#13988
  • Lint against Bar { .. }.foo.x != Foo { .. }.x:
    Detect when a field default is not using that field's type's default values #135859
    Closed, should likely live in clippy as allow-by-default. There's no analogue lint for the same case for Default, so either we should have both or neither.
• Restrict #[non_exhaustive]:
  Restrict #[non_exaustive] on structs with default field values #134539
• Add documentation entry to unstable book:
  Add default_field_values entry to unstable book #134855
• Constify Default::default() so that it can be used in default field values:
  Make Default const and add some const Default impls #134628
• Propose rustfmt style:
  Proposed formatting for default field values style-team#205
• Add test for privacy rules:
  Emit single privacy error for struct literal with multiple private fields and add test for default_field_values privacy #135700
• Disallow A { .. } if A has no fields:
  Disallow A { .. } if A has no fields #135703
• Fix lifetime checking ICE:
  Do not ICE on default_field_value const with lifetimes #135711
• Detect APIs with non-exhaustive struct constructors forcing A { field, .. } always:
  • Detect missing fields with default values and suggest .. #135794
  • Detect struct construction with private field in field with default #135846

[Phosphorus-M]

Hi @estebank , I have a question

Are we considering a syntax like the following?

#[derive(Default)]
struct Pet {
    name: Option<String>, // impl Default for Pet will use Default::default() for name
    age: i128 = 42, // impl Default for Pet will use the literal 42 for age
    foo: Foo = Foo { something: 10 },
}

#[derive(Default)]
struct Foo {
    something: i32 = 2,
}

Something like struct inception as default or overwriting the default implementation.

It's just a question, I don't have the intention to annoying, the RFC is really cool!

[estebank]

@Phosphorus-M that would indeed work, <Pet as Default>::default().name would be None and <Pet as Default>::default().foo.something would be 10. You just wouldn't be able to write Pet { .. } without specifying Pet { name: None, .. }. Also, the restriction that the default is a const might restrict what you can express (like initializing an Arc?), but your example would work as expected.

[SUPERCILEX]

I couldn't find anything in the RFC about partial defaults... would this real-world example be supported:

#[derive(Debug)]
struct App {
    epoll: OwnedFd, // ERROR: this is the only field without a default implementation

    manager: Option<AutoDestroy<ZwlrDataControlManagerV1>>,
    seats: Seats,
    pending_offers: PendingOffers,

    error: Option<CliError>,
    pending_seats: SmallVec<(u32, AutoDestroy<WlSeat>), 1>,
}

// It would be really cool if this worked by making the .. use default impls for all the other fields
let app = App { epoll, .. };

[jhpratt]

@SUPERCILEX See this section. It will be supported once the implementation is merged.

[SUPERCILEX]

Amazing, thank you and sorry for missing that!