I've extracted and slightly modified some text from Centril's draft RFC from a while back that proposed this and much more. He has granted permission for me to use the text.
- Feature Name:
derive_enum_default - Start Date: 2021-04-07
- RFC PR: TODO
- Rust Issue: TODO
Summary
An attribute #[default], usable on enum variants, is also introduced, thereby allowing enums to
work with #[derive(Default)].
#[derive(Default)]
enum Foo {
#[default]
Alpha(u8),
Beta,
Gamma,
}
assert_eq!(Foo::default(), Foo::Alpha(0));
The #[default] attribute may not be used on a variant that is also declared #[non_exhaustive].
Motivation
#[derive(Default)] in more cases
Currently, #[derive(Default)] is not usable for enums. To rectify this situation, a #[default]
attribute is introduced that can be attached to variants. This allows you to use
#[derive(Default)] on enums wherefore you can now write:
// from time
#[derive(Default)]
enum Padding {
Space,
Zero,
#[default]
None,
}
Clearer documentation and more local reasoning
Providing good defaults when such exist is part of any good design that makes a physical tool, UI design, or even data-type more ergonomic and easily usable. However, that does not mean that the defaults provided can just be ignored and that they need not be understood. This is especially the case when you are moving away from said defaults and need to understand what they were. Furthermore, it is not too uncommon to see authors writing in the documentation of a data-type that a certain value is the default.
All in all, the defaults of a data-type are therefore important properties. By encoding the defaults
right where the data-type is defined gains can be made in terms of readability particularly with
regard to. the ease of skimming through code. In particular, it is easier to see what the default
variant is if you can directly look at the rustdoc page and read:
#[derive(Default)]
enum Foo {
#[default]
Bar {
alpha: u8,
},
Baz {
beta: u16,
gamma: bool,
}
}
This way, you do not need to open up the code of the Default implementation to see what the
default variant is.
Guide-level explanation
The ability to add default values to fields of enum variants does not mean that you can suddenly
#[derive(Default)] on the enum. A Rust compiler will still have no idea which variant you intended
as the default. This RFC adds the ability to mark one variant with #[default]:
#[derive(Default)]
enum Ingredient {
Tomato,
Onion,
#[default]
Lettuce,
}
Now the compiler knows that Ingredient::Lettuce should be considered the default and will
accordingly generate an appropriate implementation of Default for Ingredient:
impl Default for Ingredient {
fn default() -> Self {
Ingredient::Lettuce
}
}
Note that after any cfg-stripping has occurred, it is an error to have #[default] specified on
more than one variant.
Due to the potential of generated bounds becoming more restrictive with an additional field, the
#[default] and #[non_exhaustive] attributes may not be placed on the same variant.
Reference-level explanation
#[default] on enums
A built-in attribute #[default] is provided the compiler and may be legally placed solely on
exhaustive enum variants. The attribute has no semantics on its own. Placing the attribute on
anything else will result in a compilation error. Furthermore, if the attribute occurs on more than
one variant of the same enum data-type after cfg-stripping and macro expansion is done, this
will also result in a compilation error.
#[derive(Default)]
Placing #[derive(Default)] on an enum named $e is permissible iff that enum has some variant
$v with #[default] on it. In that event, the compiler shall generate an implementation of
Default where the function default is defined as (where $f_i denotes a vector of the fields of
$e::$v):
fn default() -> Self {
$e::$v { $f_i: Default::default() }
}
Generated bounds
To avoid needlessly strict bounds, all types present in the tagged variant's fields shall be bound
by Default in the generated code.
#[derive(Default)]
enum Option<T> {
#[default]
None,
Some(T),
}
would generate:
impl<T> Default for Option<T> {
fn default() -> Self {
Option::None
}
}
while placing the #[default] attribute on Some(T) would instead generate:
impl<T> Default for Ptr<T> where T: Default {
fn default() -> Self {
Option::Some(Default::default())
}
}
Interaction with #[non_exhaustive]
The Rust compiler shall not permit #[default] and #[non_exhaustive] to be present on the same
variant. Any variant not designated #[default] may be #[non_exhaustive], as can the enum
itself.
Drawbacks
The usual drawback of increasing the complexity of the language applies. However, the degree to
which complexity is increased is not substantial. One notable change is the addition of an attribute
for a built-in #[derive], which has no precedent.
Rationale
The inability to derive Default on enums has been noted on a number of occasions, with a common
suggestion being to add a #[default] attribute (or similar) as this RFC proposes.
- [IRLO] Request: derive enum's default
- [IRLO] Deriving
Error(comment) - [URLO] Crate for macro for default enum variant
- [URLO]
#[derive(Default)]for enum, [not] only struct
Bounds being generated based on the tagged variant is necessary to avoid overly strict bounds. If
this were not the case, the previous example of Option<T> would require T: Default even though
it is unnecessary because Option::None does not use T.
Prohibiting #[non_exhaustive] variants from being tagged with #[default] is necessary to avoid
the possibility of a breaking change when additional fields are added. If this were not the case,
the following could occur:
A definition of
#[derive(Default)]
enum Foo<T> {
#[default]
#[non_exhaustive]
Alpha,
Beta(T),
}
which would not have any required bounds on the generated code. If this were changed to
#[derive(Default)]
enum Foo<T> {
#[default]
#[non_exhaustive]
Alpha(T),
Beta(T),
}
then any code where T: !Default would now fail to compile.
Alternatives
One alternative is to permit the user to declare the default variant in the derive itself, such as
#[derive(Default(VariantName))]. This has the disadvantage that the variant name is present in
multiple locations in the declaration, increasing the likelihood of a typo (and thus an error).
Another alternative is assigning the first variant to be default when #[derive(Default)] is
present. This may prevent a #[derive(PartialOrd)] on some enums where order is important (unless
the user were to explicitly assign the discriminant).
Prior art
Procedural macros
There are a number of crates which to varying degrees afford macros for default field values and associated facilities.
#[derive(Derivative)]
The crate derivative provides the #[derivative(Default)] attribute. With it, you may write:
#[derive(Derivative)]
#[derivative(Default)]
enum Foo {
#[derivative(Default)]
Bar,
Baz,
}
Contrast this with the equivalent in the style of this RFC:
#[derive(Default)]
enum Foo {
#[default]
Bar,
Baz,
}
Like in this RFC, derivative allows you to derive Default for enums. The syntax used in the
macro is #[derivative(Default)] whereas the RFC provides the more ergonomic and direct notation
#[default] in this RFC.
#[derive(SmartDefault)]
The smart-default provides #[derive(SmartDefault)] custom derive macro. It functions similarly
to derivative but is specialized for the Default trait. With it, you can write:
#[derive(SmartDefault)]
enum Foo {
#[default]
Bar,
Baz,
}
-
The same syntax
#[default]is used both bysmart-defaultand by this RFC. While it may seem that this RFC was inspired bysmart-default, this is not the case. Rather, this notation has been independently thought of on multiple occasions. That suggests that the notation is intuitive since and a solid design choice. -
There is no trait
SmartDefaulteven though it is being derived. This works because#[proc_macro_derive(SmartDefault)]is in fact not tied to any trait. That#[derive(Serialize)]refers to the same trait as the name of the macro is from the perspective of the language's static semantics entirely coincidental.However, for users who aren't aware of this, it may seem strange that
SmartDefaultshould derive for theDefaulttrait.
Unresolved questions
-
Should the generated bounds be those required by the tagged variant or those of the union of all variants? This matters for
enumssimilar toOption<T>, where the default isOption::None— a value that does not requireT: Default.Resolved in favor of requiring all types in the only the tagged variant to be bound by
Default.
Future possibilities
The #[default] attribute could be extended to override otherwise derived default values, such as
#[derive(Default)]
struct Foo {
alpha: u8,
#[default = 1]
beta: u8,
}
which would result in
impl Default for Foo {
fn default() -> Self {
Foo {
alpha: Default::default(),
beta: 1,
}
}
}
being generated.
Alternatively, dedicated syntax could be provided as proposed by @Centril:
#[derive(Default)]
struct Foo {
alpha: u8,
beta: u8 = 1,
}
If consensus can be reached on desired bounds, there should be no technical restrictions on
permitting the #[default] attribute on a #[non_exhaustive] variant.
Ultimately it's just me trying to figure a way to word the behavior formally.