[Idioms/Constructors] use Default instead of empty constructor

[wookietreiber]

TL;DR: Use Default instead of fn new().

The constructors section currently shows an example with fn new(), i.e. a constructor without arguments. For data structures like this, it is often useful to provide a Default implementation. Default is used in a few places in libraries, e.g. in std in Option::unwrap_or_default, Result::unwrap_or_default, or Entry::or_default, so it's definitely useful to have.

When there is a Default implementation, and for data structures with empty constructors there arguably should be one, providing fn new() is unnecessary, even counterproductive.

My suggestion is to explain exactly this in the constructors section, maybe even using the variants provided below: going from a less capable version (no default), to having a more capable version (with default), to having even less code than in the initial example (derived default).

Note: I know that there is also a section about Default itself. Since I'm advocating for Default instead of fn new(), you might even want to swap these sections, so the section about Default gets read before the one about constructors. I can also imagine to merge these sections.

Variant A: only new without arguments

struct VariantA {
    o: Option<i64>,
}

impl VariantA {
    fn new() -> Self {
        Self { o: None }
    }
}

Note: This variant doesn't have a Default implementation.

Variant B: new + manual Default

struct VariantB {
    o: Option<i64>,
}

impl VariantB {
    fn new() -> Self {
        Self { o: None }
    }
}

impl Default for VariantB {
    fn default() -> Self {
        Self { o: None }
    }
}

Note: This example shows duplicated code. But one could also implement new using Self::default() or implement Default using Self::new(). Which one should I choose? Avoid this unnecessary decision by not implementing both. One might even make the mistake of having different implementations for new and Default. #dangerzone

Variant C: new + derived Default

#[derive(Default)]
struct VariantC {
    o: Option<i64>,
}

impl VariantC {
    fn new() -> Self {
        Self::default()
    }
}

Note: Here, I opted to use Self::default() in new. But I could also have implemented it as Self { o: None }. This would be code duplication as well, you just don't see it because of #[derive(Default)].

Variant D: only Default

#[derive(Default)]
struct VariantD {
    o: Option<i64>,
}

Note: You can't get by with writing less code, which reduces complexity and means less code maintenance.

Drawback

For programmers coming from other languages, Default may be a new concept. They might look for new constructors instead of checking if there is a Default implementation and wonder where the constructor is. This could be handled if rustdoc would more prominently show that there is a Default implementation. Currently, you usually have to scroll way down to see if there is one.

Personal Summary

I find having Default in Rust is awesome. I use Default for all of my data structures that are able to be constructed without arguments. Once I realized that it is functionally equivalent to having fn new() in terms of having a constructor without arguments, and even more functional by being able to be used in places where libraries require Default, I have stopped implementing fn new(), and you can too! 😄

[wookietreiber]

Forgot to mention this: having both Default and fn new() means you have two ways to do the same. This kind of goes against the principle that there should be exactly one way to do something. Having more ways is generally more complexity that can be avoided.

(I don't know if this principle has a name, like KISS or DRY.)

[simonsan]

I want to cite from Elegant Library APIs in Rust:

[^1:] If you can construct your type without any parameters, you should implement Default on it, and use that instead of new. An exception to this is new on “container” types, like Vec or HashMap, where it makes sense to initialize an empty container.

Also Rust API Guidelines:

Note that it is common and expected for types to implement both Default and a new constructor. For types that have both, they should have the same behavior. Either one may be implemented in terms of the other.

@wookietreiber Do you want to make a pull request with the changes you propose?

[wookietreiber]

Yes, I will.

[simonsan]

Please make a pull request early on, so we can figure out in which direction we go together. So you don't write too much and we end up in misunderstandings. Cheers.