You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now when using #[num_enum(default)] or #[num_enum(default)] with TryFromPrimitive it just ignores them.
But it's more reasonable to return error because of missing support.
The text was updated successfully, but these errors were encountered:
This is a really interesting question to consider, thanks for raising it!
My initial instinct is that it's unusual to derive both FromPrimitive (which supports default) andTryFromPrimitive (which doesn't) - in general, either an enum always has a reasonable default (where FromPrimitive makes sense), or the default is context-specific (and FromPrimitive doesn't have the context of how/where it's being used, so TryFromPrimitive makes sense, and the caller should probably do something like try_into().unwrap_or_default(..)).
Which suggests that we should probably error if num_enum(default) is present and TryFromPrimitive is being derived.
That said, this would be a breaking change, as currently it is possible to derive both. It probably makes sense to make that change though.
Out of interest did this cause you a real problem when using the library, or did you just notice the inconsistency and raise it? Both are valid reasons to fix this, but if you ran into a problem as a result of this issue I'd lean much more heavily towards fixing this soon.
Now when using
#[num_enum(default)]
or#[num_enum(default)]
withTryFromPrimitive
it just ignores them.But it's more reasonable to return error because of missing support.
The text was updated successfully, but these errors were encountered: