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

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

@rustbot

@rustbot modify labels to +F-default_free_fn

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.

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

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

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().

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() }.

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.

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

Is there a reason why this new free function isn't added in the prelude when the feature default_free_fn is used?

The final comment period, with a disposition to close, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

Rollup merge of rust-lang#113469 - JohnTitor:rm-default-free-fn, r=Am…

So, the feature has been removed in favor of a language change, but without actually formally proposing the language change? Disappointing.

@rfcbot

We discussed this in the libs-api meeting today. We would prefer to see a language feature to import the Default::default method directly. The language team seems to be open to this, but someone needs to write up a language proposal and drive the design of this feature.

Since we are unlikely to stabilize the default function as-is, we would like to remove it from the standard library.

@rfcbot fcp close

TL;DR

maybe we can have a language feature (alias) specifically for when creating structs with StructName {} to support .. which expands to ..Default::default.

Example:

MyStruct {
  a: 1,
  b: 2,
  ..,
}

This makes sense because the language already has this syntax is places such as pattern matching

has there been any followup RFC/tracking issue for an eventual use Trait::method; syntax?

has there been any followup RFC/tracking issue for an eventual use Trait::method; syntax?

For what it's worth, rust-lang/rfcs#1995 is an open issue on this, maybe we could have some discussion there to move things forward.

Navigation Menu

Repository navigation

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

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

Steps

Unresolved Questions

Implementation history

41 remaining items

Example:

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

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

Steps

Unresolved Questions

Implementation history

Activity

illia-bobyr commented on Jun 5, 2020

bluss commented on Jun 5, 2020

illia-bobyr commented on Jun 5, 2020

RalfJung commented on Jun 5, 2020

illia-bobyr commented on Jun 6, 2020

birkenfeld commented on Jun 12, 2020

bestouff commented on Jun 17, 2020

illia-bobyr commented on Jun 19, 2020

robinmoussu commented on Nov 18, 2020

41 remaining items

rfcbot commented on Jul 7, 2023

dscottboggs commented on Jul 20, 2023

minghu6 commented on Aug 18, 2023

DanieliusDev commented on Sep 3, 2023

Example:

LunarLambda commented on Nov 29, 2023

crumblingstatue commented on Dec 29, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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