Correct the partial initialization of a struct

[iddm]

Here is a question about the partial initialization of a struct. The answer there says that to use the ..Default::default() syntax your type must implement the Default trait, however, I don't see any reason for this.

Assume we have the following code:

struct A {
    field: u64,
}
struct B {
    field_a: A,
    field_b: Option<bool>,  // Option<bool> implements `Default` trait
    field_c: Option<String>,  // Option<bool> implements `Default` trait
    field_d: bool,    // bool implements `Default` trait
}

So, when we want to partially initialize it we actually don't need a Default trait to be implemented for our struct B, but we do for it's fields which we don't initialize (we initialize them by using Default):

impl B {
    fn new(a: A) {
        B {
            field_a: A,    // We have just specified the field which does not implement `Default` trait
            ..Default::default()    // We have said that everything else is constructed with default values because their types implement Default trait
        }
    }
}

So, there is really no need in Default trait to be implement for the whole structure B if it's fields do that. You simply don't even touch the Default trait of B structure, but you do that for it's fields!

Can we improve partial structs initialization not to require Default trait for the whole type if we don't use it actually?

[TimNN]

Inferring from your post, I think you are missing a key fact: The B { field_a: A, ..xyz } syntax has nothing to do with Default: It merely states "initialise the explicitly given fields and take the rest from xyz (where xyz is an instance of B)"

So the current syntax always requires a completely constructed object. What is proposed here, initialising missing fields individually by some method, would be an entirely new feature I think (and thus https://github.com/rust-lang/rfcs may be a better place for this issue).

[Mark-Simulacrum]

Yes, this change would need an RFC. If you'd like to pursue this, please go through the RFC process. You can start by either filing an issue on rust-lang/rfcs or starting a thread on internals.rust-lang.org to discuss this.

[iddm]

@Mark-Simulacrum, @TimNN okay, I will make an rfc.

[iddm]

@TimNN Could you point me do the docs which explain current behavior please?

Inferring from your post, I think you are missing a key fact: The B { field_a: A, ..xyz } syntax has nothing to do with Default: It merely states "initialise the explicitly given fields and take the rest from xyz (where xyz is an instance of B)"

[TimNN]

@vityafx:

See either the second edition of the Book, the first edition of the Book or the Reference.

[iddm]

@TimNN Thanks! Sorry for asking a question again, could you also point me to the source code where this syntax is parsed? I am working on "Implementation details" part now of the rfc..

[TimNN]

@vityafx: No problem! The parsing happens here as far as I can tell, although you shouldn't need to look at that code to write the RFC.

[iddm]

@TimNN yes, I understand that :) I just want to implement the feature by myself and try some variants of it. Thanks a lot for the link!

[steveklabnik]

I believe @ubsan was recently asking about this as well; maybe they'd be interested in getting involved

[strega-nil]

not me, sorry! The only thing I'm really interested in is allowing Xyz<T> { t, ..xyz } where xyz is an Xyz<U>.

[kahing]

I workaround this by having a Required type that's an Optional, which implements Deref and DerefMut that unwraps the said Optional. A bit of a hack but works fine.

[rlidwka]

The answer there says that to use the ..Default::default() syntax your type must implement the Default trait, however, I don't see any reason for this.

Default values for a struct may be different from default values of any individual struct member.

#[derive(Debug)]
struct A {
    one: i32,
    two: i32,
    three: i32,
}

impl Default for A {
    fn default() -> Self {
        A {
            one: 1,
            two: 2,
            three: 3,
        }
    }
}

dbg!(A {
    one: 111,
    ..default() // expecting `two: 2`, not `two: 0`
});

Thus, you cannot initialize struct with default values of each struct members, that would be ambiguous and/or break backward compatibility.

[iddm]

Yes, it is ambiguous and would require breaking backwards compatibility. That's why I am not so sure anymore whether it is good to have it, or we could just live with it.

[m1guelpf]

@vityafx Did you ever get around to writing an RFC for this?

[iddm]

@vityafx Did you ever get around to writing an RFC for this?

Can't remember, probably not.