Tracking issue for std::default::default()

[ilya-bobyr]

The feature gate for the issue is #![feature(default_free_fn)].

Addition of a free default() function to the default module.

When constructing a value using Default::default() the word "default" is repeated twice.

See #73001 for additional details, including alternative solutions.

Steps

• Implement the RFC: Free default() forwarding to Default::default() #73001
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)
• Update examples in the documentation that currently use Default::default() to use default() where it makes sense.

Unresolved Questions

• Should the language allow direct import of trait methods, this feature becomes redundant. This addition is likely to be stabilized only when we decide that direct import of trait methods is will not be supported.

Implementation history

[ilya-bobyr]

@rustbot modify labels to +F-default_free_fn

[bluss]

You call out Default::default() in the description here - but why aren't T::default() or <$any_type>::default() good alternatives? They work today, if the Default trait is in scope, and it is in the prelude.

[ilya-bobyr]

T::default() is convenient when the compiler can not infer the type. But when it can, T because redundant. Here is a discussion where this was mentioned as well: #73001

[RalfJung]

FWIW I think it is often still good style to say T::default() to communicate to the human reader the type being constructed away, which can be declared very far away in the code (even in a different file).

[ilya-bobyr]

FWIW I think it is often still good style to say T::default() to communicate to the human reader the type being constructed away, which can be declared very far away in the code (even in a different file).

I do no think this change takes away that and in certain cases you have to say T::default(). The change allows you to say default() in cases where you are currently saying Default::default().

[birkenfeld]

You call out Default::default() in the description here - but why aren't T::default() or <$any_type>::default() good alternatives? They work today, if the Default trait is in scope, and it is in the prelude.

Default::default() happens a lot in struct displays, with StructType { ..., StructType::default() } being as redundant as StructType { ..., Default::default() }.

[bestouff]

A bit late to the party, but why not just a use Default::default() in the prelude instead ?
That's less code to inline for the optimizer.

[ilya-bobyr]

A bit late to the party, but why not just a use Default::default() in the prelude instead ?
That's less code to inline for the optimizer.

I am not sure I understand exactly what are you suggesting. But if the motivation described in the issues summary is not enough, please, read the discussion in #73001