Replace FromPrimitive with our own tag macro #63
Conversation
Factor out parts that are unique to instantiations such as the name, the documentation, the underlying type, the public conversion methods. Also adds the ability to document individual items and remodels the syntax to more closely resemble ordinary enum definitions.
Several other uses that currently rely on num-traits for conversion have no Unknown representation. Thus, the converter now outputs only known variants or an error and the exposing function then can put the error value into an Unknown variant instead.
The discriminant of some enum types can be retrieved with the `as` operator and in C style enums it is also possible to set a specific discriminant. However, that may silently change—breaking the value written to the file. It is better to use that technique mostly for ffi purposes.
| $(if n == $val { Tag::$tag } else)* { | ||
| Tag::Unknown(n) | ||
|
|
||
| impl $name { |
There was a problem hiding this comment.
I'm coming to this somewhat late so perhaps I'm missing some context, but is there a reason not to replace the methods below with impls of TryFrom<$ty> for $tag and From<$tag> for $ty?
There was a problem hiding this comment.
I thought I'd minimize the public interface that comes from within the macro. It might still be a good idea to expose those.
Yeah, sadly. We'll get |
Thanks to the review comment for pointing this style issue out.
Turns out the only use was as a private bound which was unused within that method.
This is more flexible and removes the dependency.
Note that
FromPrimitivewas used with only a single primitive type as the source. This not only increases the public interface much more than necessary but is also misleading. All fields that can be converted as such have specified widths iirc.The
num-derivecrate does also not handle non-exhaustiveness which is a major future compatibility hazard as more tags etc. are to be supported.Closes: #57, #59