Allow to elide fields with types that implements `Default` for struct literals

[bombless]

Allow you to elide some fields in struct literals.
So with

struct Foo { a: i32 }

you can write Foo {} to get Foo { a: 0 }.

[ticki]

1. Making this implicit seems like a bad idea. Forgetting to write a field will lead you into all kinds of unexpected bugs.
2. This actually already exists (autofilling default fields):

#[derive(Default)]
struct Foo {
    a: i32,
}

fn main() {
    let bar = Foo { .. Default::default() };
}

You can even override default fields!

[glaebhoerl]

Hmm. There are two separate avenues here:

1. If the struct itself implements Default, use that to fill in the missing fields (what @ticki mentioned)
2. If the type of the field implements Default, use that to fill in the missing field (what @bombless proposed)

These two can of course be completely different in practice. The first one seems more appropriate to me, though I can't immediately articulate a reason.

I agree with @ticki that having it be completely implicit seems questionable, but I wonder if having just .., with no value specified, be equivalent to .. Default::default() might be alright? It would cut down on verbosity at least.

(Incidentally how come this syntax - even the existing one - isn't ambiguous with ranges...?)

[Stebalien]

I'd love this.

@glaebhoerl,

1 isn't ambagious with ranges because rust expects .. something, name: value, or } here. 2 would definitely be ambiguous (you'd need Foo {a: ..} which would desugar to Foo {a: RangeFull}).

[ticki]

I agree with @ticki that having it be completely implicit seems questionable, but I wonder if having just .., with no value specified, be equivalent to .. Default::default() might be alright? It would cut down on verbosity at least.

I like that idea!

(Incidentally how come this syntax - even the existing one - isn't ambiguous with ranges...?)

Because, when you override fields, you need a comma in front of the ...

[ticki]

@Stebalien

I'd love this.

1. or 2.?

[Stebalien]

@ticki, I mean:

#[derive(Default)]
struct Foo {
    a: usize,
    b: usize,
}

fn main() {
    let foo = Foo { a: 1, ..}; // == Foo { a: 1, .. Default::default() }
}

[ticki]

I agree that .. not followed by anything should default to Default::default().

[Stebalien]

Related: https://internals.rust-lang.org/t/allow-a-trailing-in-a-struct-literal-meaning-default-default/885

[glaebhoerl]

(Oh right, it slipped my mind that field names are also specified in struct literals, which is why ranges and functional update are unambiguous.)

[nixpulvis]

Not the same but related, what about for support for something like this?

fn main() {
    #[derive(Debug, Default)]
    struct Point2D {
        x: u32,
        y: u32,
    }

    #[derive(Debug, Default)]
    struct Point3D {
        x: u32,
        y: u32,
        z: u32,
    }

    let p2 = Point2D { x: 1, y: 2 };
    let p3 = Point3D { z: 3, .. p2 };
    println!("{:?}", p3);
}

[petrochenkov]

Foo { a: 1, ..Default::default() } means constructing a whole new Foo and then dropping unused fields, including running all possible side effects involved in construction/destruction of the unused fields.
It will probably not affect performance given optimizations and conventions around Default, but it still feels wrong ideologically.

C and C++ implement @glaebhoerl's variant 2 for fields omitted in initializers (with some nuances, as always).

[glaebhoerl]

One way we could avoid those issues would be to use an associated const instead of an fn (so presumably this would have to be a new trait, not the existing Default), but that would also greatly restrict the set of types which it could work with. It does feel wrong from the "costs are explicit" perspective (among others) that an innocuous-seeming .. could hide arbitrarily costly and complex function calls, allocation, initialization, etc. Then again, if strong cultural norms are good enough for Deref, then I don't see why they couldn't be good enough for Default - we'd just have to make it clear what they are.

[Stebalien]

@glaebhoerl the const fn RFC notes the possibility of const impl MyTrait some time in the future. However, I actually don't really mind throwing those fields away; I see this as mostly being used as a way to pass keyword arguments to a function.

[nielsle]

I really like Glaebhoerls idea (as presented by Stebalien). This could also be used for simple APIs with optional arguments #323

fn foo(3, Args{bar:7, ..})    // Perhaps future sugar could allow "fn foo(3,  {bar:7 ..})"