enum support in 0.12 breaks --derive Default

[doy-materialize]

the enums generated by 0.12 (#65) don't label which variant is the default, so if you try using --derive Default, you will end up with a lot of errors like

error: no default declared
    --> foo/bar/baz.rs:1116:48
     |
1116 | #[derive(Serialize, Deserialize, Clone, Debug, Default)]
     |                                                ^^^^^^^
     |
     = help: make a unit variant default by placing `#[default]` above it
     = note: this error originates in the derive macro `Default` (in Nightly builds, run with -Z macro-backtrace for more info)

[clux]

oh, there's not a great way to solve this; what are we supposed to do?

• if the enum is nested within a struct that derives default, then the enum needs to impl Default (so we can't just skip it for enums)
• we can't just pick a default (if it's not specified in the schema)

So either we have to tell the user to impl Default for EnumVariant or we have to bail! if there's no specified default in the schema. Not sure what is good to do here immediately.

[clux]

Actually, I think the sane thing for us to do is to:

• never add #[derive(Default)] to an enum - done in Stop auto-deriving default for enum #89
• if we see a default value in the schema; then add a special impl Default for ThatEnum - via handle default field #67
• if we don't see that; leave it missing, requiring the user to impl Default for ThatEnum - (nothing we can do in this case)

[clux]

Master has a partial fix for this now. We will no longer add #[derive(Default)] to enums.

This will still end up not compiling in the larger context, but you can at least now sideload a impl Default for the enum to fix it. We can never truly fix this for all cases (if it's not in the schema), and for the cases we can cover, I'll defer to issue #67.

[mt-inside]

Thanks very much for this @clux , I was just about raise this and suggest that exact solution.