Free default() forwarding to Default::default()

[ilya-bobyr]

It feels redundant to have to say Default::default() every time I need a new value of a type that has a Default instance.
Especially so, compared to Haskell, where the same functionality is called def.
Providing a free default() function that forwards to Default::default() could improve the situation.
The trait is still there, so if someone wants to be explicit and to say Default::default() - it still works, but if imported as std::default::default;, then the free function reduces typing and visual noise.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Mark-Simulacrum (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[Mark-Simulacrum]

r? @dtolnay as this is an unstable addition to standard library surface so should get libs team attention.

---

That said, speaking personally, I don't think this is a good move. I have usually found that uses of Default::default() are usually a poor choice in the long run -- I prefer T::default() in generic contexts or SomeType::default() where possible.

[ilya-bobyr]

When you need to be explicit about the type - I totally agree, you want T::default().
But in certain contexts type can be inferred. This is where, currently, one needs to say Default::default(). And this is what the Default documentation currently suggests as well.

For example, when changing a value of some of the fields in the struct:

let options = SomeOptions { foo: 42, ..Default::default() };

I do not think it adds a lot of clarity if you repeat the type names twice:

let options = SomeOptions { foo: 42, ..SomeOptions::default() };

[petrochenkov]

I'd rather make use Default::default; (and any use Trait::trait_item;) work at language level.
It should be a pretty minor change from both compiler and language point of view because it's mostly equivalent to already supported use Enum::Variant;.

(As for SomeOptions { foo: 42, ..Default::default() } specifically, it's probably better solved at language level as well with SomeOptions { foo: 42, .. }.)

EDIT: There are existing issues for both of these features somewhere in this or the rfcs repo, but I can't find them right now.

[Mark-Simulacrum]

Yeah, I would prefer a language solution too I think :)

I will also note that I think I've used the .. syntax in structs maybe twice over the last ~3+ years of Rust development, so it doesn't immediately jump out at me as sufficient justification for a new library function; but maybe its usage is more common in some areas of Rust code I am unfamiliar with.

[dtolnay]

I don't have high confidence that the language change will happen, as much as it would be better, so I am on board with landing this unstable.

We probably wouldn't stabilize until use Default::default; is ruled out though.

[dtolnay]

Thanks! I like this example code better.

[ilya-bobyr]

Thanks for the review!

Spent some time looking for existing proposals on extending the language to allow direct import of trait methods but did not find anything. Thought, language change would be a much, much larger time investment, also requiring more expertise. Not sure if I would be able to pull it off.

[bluss]

Since there is no RFC I will put in a couple of questions here.

We have the following existing alternatives:

1. T::default() if the type is known or partially known. Note that we can use path-like syntax PathLike::default() and type syntax <Type>::default().
2. <_>::default() as a special case of the type syntax when the type is to be inferred. This works the same way as the free function in this PR.
3. Default::default.

The existing syntaxes have the following benefit. Using an explicit type makes the code easy to read, when the explicit type is the "source" of the type, this becomes the best option. Even when the type would be redundant, it can, as a matter of taste, still be good code style. Instead of let x: T = Default::default(), prefer let x = T::default() instead.

The <Type>::default() syntax allows partial inference, for example like <HashMap<_, _>>::default() (pick a hashmap with the default for the hasher parameter).

The <_>::default() syntax has the benefit that it allows full type inference, and that it works as long as the Default trait is in scope. So it has power equal to the free function being added here.

The drawback would be if you don't think this is good-looking or easy to understand code.

4. A fourth alternative is that the user defines its own equivalent default() function.

I wrote this so that we know the alternatives, so that they can be specifically addressed w.r.t stabilization of this.

[bluss]

This is a nitpick I'd mention in any PR, but I guess it's extra strange now - here, why don't we prefer using the style T::default()?

[dtolnay]

I would like to stick with Default::default(). The documentation of the function describes it as being equivalent to Default::default() and this reinforces that, even if T::default() would also be equivalent. It would be less clear for the documentation to describe the function as being equivalent to T::default() because T::default() has type T while Default::default() has a type that is filled in by inference.

[bluss]

I guess I'm here because avoiding Default::default is a pet peeve of mine, which in some way I must partly share with ilya-bobyr then. Since we say equivalent, any equivalent code would be fine, and I think we should prefer the style that we would like to see in Rust codebases around the ecosystem, hence T::default().

If the docs say Default::default, maybe that could change now or in the future.

[ilya-bobyr]

Default::default() was the first thing I thought about, as this is what I was trying to replace. If @dtolnay likes Default::default() more here, I would just leave it.

[dtolnay]

@bluss In response to #73001 (comment): I don't disagree with anything in there but I don't see this as being a replacement for let x = T::default(); i.e. let x: T = default(); is not better. Where this comes up in my codebase is when instantiating Thrift-generated data structures which look a lot like the example code in the PR.

let zw = ZWriteData { key, ..default() };

When there are a lot (sometimes 100+) of these in a file it's reasonable to want to import Default::default, and the suggestions of ZWriteData { key, ..ZWriteData::default() } or ZWriteData { key, ..Default::default() } or ZWriteData { key, ..<_>::default() } are not better, whether due to repetition or an intimidating amount of punctuation.

[dtolnay]

@bors r+

[bors]

📌 Commit ebb8722 has been approved by dtolnay

[RalfJung]

@bors rollup

[leonardo-m]

An usage example of default could be added to Vec::resize_with.

[ilya-bobyr]

An usage example of default could be added to Vec::resize_with.

Agreed. But maybe when the feature is stabilized?

As David Tolnay (dtolnay) said: "I would prefer not to feature an unstable API so heavily in the doc of an extremely widely used trait."
And it totally makes sense: one can used unstable features only when using nightly build or when compiling rustc yourself.

[dtolnay]

Yeah that should be a checklist item in the tracking issue. It can be done in the stabilization PR or a separate PR just beforehand.

[ilya-bobyr]

I've added an item to the tracking issue.

[jyn514]

EDIT: There are existing issues for both of these features somewhere in this or the rfcs repo, but I can't find them right now.

rust-lang/rfcs#1995

[hkBst]

Since there is no RFC I will put in a couple of questions here.

We have the following existing alternatives:

1. `T::default()` if the type is known or partially known. Note that we can use path-like syntax `PathLike::default()` and type syntax `<Type>::default()`.

2. `<_>::default()` as a special case of the type syntax when the type is to be inferred. This works the same way as the free function in this PR.

3. `Default::default`.

The existing syntaxes have the following benefit. Using an explicit type makes the code easy to read, when the explicit type is the "source" of the type, this becomes the best option. Even when the type would be redundant, it can, as a matter of taste, still be good code style. Instead of let x: T = Default::default(), prefer let x = T::default() instead.

The <Type>::default() syntax allows partial inference, for example like <HashMap<_, _>>::default() (pick a hashmap with the default for the hasher parameter).

The <_>::default() syntax has the benefit that it allows full type inference, and that it works as long as the Default trait is in scope. So it has power equal to the free function being added here.

The drawback would be if you don't think this is good-looking or easy to understand code.

4. A fourth alternative is that the user defines its own equivalent `default()` function.

I wrote this so that we know the alternatives, so that they can be specifically addressed w.r.t stabilization of this.

5. You can use Default as D; locally, to be able to use D::default().

ad 4. this user-defined alternative could be called d, or def, or whatever is to the user's taste:

#[derive(Default)]
struct Struct {
    member1: u128,
    member2: u128,
}

fn d<T:Default>() -> T {
    T::default()
}

fn main() {
    use Default as D;
    Struct { ..Default::default() };
    Struct { ..D::default() };
    Struct { ..d() };
}