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
Would you be open to adding or accepting a PR that would implement Into for multiple int types?
For context, the codebase I'm working with has several generated enums. We're currently pushing to eliminate as much as castings and funnel all enum -> int conversions through a less "foot-gunny" API. In some instances, we're using #[repr(u32)] enums as a u64.
What's currently barring us from using https://github.com/rust-num/num-derive is it assumes the variant can validly be represented as a i64. It doesn't take into consideration the repr, which would defeat the purpose of eliminating this footgun. Even though it'll be unlikely we'll encounter this issue, we would still like to be safe 🧷.
The text was updated successfully, but these errors were encountered:
Hi 👋.
Would you be open to adding or accepting a PR that would implement
Into
for multiple int types?For context, the codebase I'm working with has several generated enums. We're currently pushing to eliminate as much
as
castings and funnel all enum -> int conversions through a less "foot-gunny" API. In some instances, we're using#[repr(u32)]
enums as au64
.What's currently barring us from using https://github.com/rust-num/num-derive is it assumes the variant can validly be represented as a
i64
. It doesn't take into consideration therepr
, which would defeat the purpose of eliminating this footgun. Even though it'll be unlikely we'll encounter this issue, we would still like to be safe 🧷.The text was updated successfully, but these errors were encountered: