Skip to content

Missing TryFrom<NonZeroFoo> for NonZeroBar #77258

New issue

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

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

Already on GitHub? # to your account

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
# for free to join this conversation on GitHub. Already have an account? # 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