Open ljbade opened 12 months ago
@ljbade : Thanks for reporting this. I had looked at having a derive Default
available in the past. At-least back then in the standard library the default
support for Enum
types was not present, and while I agree this is handy, finding it during code generation for which to use [derive(Default)]
and for which to omit is a bit of a challenge. Probably revisit this and see if this is useful.
In the meanwhile some way this can be handled is -
In your app crate, make this generated code as part of the crate (keep the generated code private or crate-public) and then you can do a derive on that crate.
An example of this can be seen here
I will still revisit the default for Enums
and see if that can be done without additional crate dependencies.
I see what you mean about the default value for Enum
, but even if I only had to fill out those then it would still save a lot of effort.
I will try your example, that might work
I see what you mean about the default value for
Enum
, but even if I only had to fill out those then it would still save a lot of effort.
The issue here is - you have to have all members Default
otherwise the compilation of the generated code fails. It's not impossible to add code for impl Default for SomeEnum
during code generation, but which of those values is default
will be very application specific. Hence I liked the approach mentioned above. Because often for most of the structs some 'utility' impl
blocks will be needed.
I will revisit this and see if this can be done in a manner that makes sense for most use cases (it will be opt-in and not opt-out) otherwise close this issue with appropriate reasoning.
Make sense?
Adding a option to derive
Default
would make it easier to fill out large structures which are mostly left atNone
or 0