What else can it do?

[Milo123459]

Would be cool if we could have something like:

aws: Default::default(),
battery: Default::default()

which autodefault could solve I suppose. Maybe making it so you could do:

aws,
battery

etc.

[zetanumbers]

This would conflict with field punning.

[zetanumbers]

aws: aws or aws: Default::default()

[Milo123459]

I don't mind, it just might be a cool feature

[zetanumbers]

We might use ..[foo, bar] syntax for that, it seems to not conflict with anything really.

[Milo123459]

Alright, cool

[Lucretiel]

I'd be more into this if there was a way to make it automatically fill in defaults for all remaining fields:

{
    a: false,
    b: 0,
    c: "",
    d: None,
    e: 10
}

would be

{
    e: 10,
    ??
}

But the main reason I want this is for implementing default on large structs, so I'm not seeing another good way to do it

[Milo123459]

All good ideas! I don't really mind

[zetanumbers]

{
    e: 10,
    ??
}

Uh, i wish that was possible. Sadly syn crate is not that flexible. We would have to reimplement the entire parser for this as far as i am aware.

Function-like macros are the only way i can think of that would be maintainable.

[Milo123459]

Ideally I think what having the usage being
{
??
}
would be best.

[zetanumbers]

There is one issue, that aims to simplify writing Default::default() to default(). I think we could demangle second one into first as a bonus.

[Lucretiel]

There is one issue, that aims to simplify writing Default::default() to default(). I think we could demangle second one into first as a bonus.

I mean, we could, but why bother? The purpose of the "naked default" change is as a convenience for code authors; proc macros like autodefault can prefer to write extremely verbose code that doesn't risk accidentally experiencing a name collision, and don't need to worry so much about emitting concise code. You'll notice that in the actual code, we emit ::core::default::Default::default(), to ensure that there are no issues if the user has their own local items called default or Default.

[zetanumbers]

Yes, i was silly there actually. We could just add a helper function named default(), it's has very simple one way to implement it. But that would require having two crates: marcos implementations and helper functions. I think it could be useful to have these "default utilities" as one dependency tho.
So i thought if we would detect use core::default::default at the root of the function's body, then substitute default() with Default::default(), but then i realized that would be doing compiler's job lol.

[zetanumbers]

Edit above: made my saying clearer