Default values for struct fields

[nrc]

strawman syntax:

struct Foo {
    a: String,
    b: i32 = 42,
}

To instantiate:

let f = Foo { a: "Hello".to_owned() };  // b gets default value of 42
let f = Foo { a: "Hello".to_owned(), .. };  // alternative syntax to make default use explicit
let f = Foo { a: "Hello".to_owned(), b: 51 };  // b is 'overridden'

cc https://internals.rust-lang.org/t/struct-field-defaults/3412

[ticki]

I would much rather introduce .. as a sugar:

MyStruct {
    a: 2,
    .. // means:   .. Default::default()
}

[birkenfeld]

Would the default be an arbitrary expression, executed at Foo creation time, or a constant expression? The latter would make this a lot less useful than default().

[keeperofdakeys]

At the very least the syntax for using the default should be explicit (IE: using ..), otherwise this feature could become slightly confusing.

[ambrop72]

Hi, I think .. or similar should not be required to enable backward compatibility. Assume a library now has a struct with some fields, it would be possible to add another field with a default value without breaking client code that initializes only the old fields. Specifying default values in the struct declaration should be sufficient permission to omit them in the initialization.

[HeroesGrave]

There was a bit of discussion on this about a year ago here: https://www.reddit.com/r/rust/comments/2m99ly/idea_for_default_struct_fields/

Probably the most important thing about this proposal is that's it's providing more flexibility than just Default, as you can have default fields for a struct that isn't neccessarily default altogether.

[mark-i-m]

It would be cool to provide both a const initializer (via default values) and a non-const one (via the Default). This is actually already possible via const functions, but it is a bit verbose IMHO. I think this would eliminate a lot of uses of lazy_static.

Example:

// In some library
pub struct Bar {
    ... // internals
}

// In my code
struct Foo {
    i: u64,
    b: Bar,
}

static f: Foo = Foo {
   i: 34,
   b: Default::default(), // Ooops! Cannot do this because `default` is non-const
};

In many cases, this leads to the use of a lazy_static, which may still be the right solution in a lot of cases. But the fact that we cannot use Default for static initializers is a bit unfortunate.

[kindlychung]

Also useful in a case like:

struct Point {
    pub x: f64,
    pub y: f64,
}

When later on you want to add a new field:

struct Point {
    pub x: f64,
    pub y: f64,
    norm: f64 = NAN,
}

impl Point {
   pub fn get_norm(&self) -> f64 {
        if(self.norm.is_nan()) {
            ...
        } else {
           self.norm
        }
   }
}

you don't have to change code across the whole project to add norm into every Point.

[ticki]

@kindlychung I think that mess with the goal of explicitness.

[sickHamm]

Whether support private fields？ I think like this code Foo { a: "Hello".to_owned(), .. } will be good way to initialize private fields.
Now， must do like this

Struct Foo {
          ...，
         pub __hide，
}
Foo { a: "Hello".to_owned(), ..Foo::default() };

[Centril]

Closing in favor of #1806 for tracking purposes.