Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing TryFrom<NonZeroFoo> for NonZeroBar #77258

Closed
Hawk777 opened this issue Sep 27, 2020 · 0 comments · Fixed by #77339
Closed

Missing TryFrom<NonZeroFoo> for NonZeroBar #77258

Hawk777 opened this issue Sep 27, 2020 · 0 comments · Fixed by #77339
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@Hawk777
Copy link

Hawk777 commented Sep 27, 2020

TryFrom<T> is implemented for type U for a lot of different integer combinations (e.g. TryFrom<u128> for u64). However the corresponding NonZero variants are not. This seems like an omission: I would expect TryFrom<NonZeroU128> for NonZeroU64. The alternative is to convert to a u128 first, throwing away the knowledge that the value is nonzero, then try to convert it to a u64, then try to convert it to a NonZeroU64 knowing that the latter conversion cannot fail (one is then faced with the choice to either use an unsafe call to new_unchecked, or a potentially unnecessarily slow call to new even though you know the zero check is pointless because the value came from a NonZeroU128 to start with and therefore cannot possibly be zero).

I saw #72712 which is related, but I thought this was a somewhat separate issue because #72712 talks about conversions from primitives to nonzeroes of different widths, while I am interested in conversions between nonzeroes of different widths—for which infallible cases already exist (e.g. From<NonZeroU32> for NonZeroU64), only the fallible ones are missing.

A bug ticket might not be quite the right forum for this; if that is the case, my apologies.

@Hawk777 Hawk777 added the C-bug Category: This is a bug. label Sep 27, 2020
@LeSeulArtichaut LeSeulArtichaut added C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. and removed C-bug Category: This is a bug. labels Sep 27, 2020
@bors bors closed this as completed in 8e37330 Oct 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants