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
• Adjust documentation (see instructions on rustc-dev-guide)
• 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]?
• Customization of behavior wrt. visibility rules (allow user to specify that value can be constructed with .. covering defaulted field that otherwise is not accessible)
• Allowing .. on types with no default fields, particularly in unit structs?
• Allowing the use of field_name: _ to specify the use of the default for that specific field?
• Tuple structs and tuple variant support
• 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")
• Expand support to non-const values?

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
• Restrcit #[non_exhaustive]: Restrict #[non_exaustive] on structs with default field values #134539

[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.

[jhpratt]

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