Impl Range and RangeInclusive for NonZeroU<*>

jalil-salame · April 23, 2023, 11:05am

note: I am only speaking about unsigned non zero integers

Problem

Currently, when looping over a range of NonZeroU<> integers, you have to use the awkward NonZeroU<*>::new or NonZeroU<*>::new_unchecked functions, even though Ranges of NonZeroU<> values are trivial:

A range of unsigned integers is either empty or it contains zero in exactly one case: when it starts from zero, thus any NonZeroU<*> Range, inclusive or otherwise, will never panic/be undefined behavior.

Am I missing something or has this not yet been worked on?

Use case

A bit contrived, but I am currently working on a Sudoku solver, it uses 0 to represent an empty cell, thus Option<NonZeroU<*>> is a natural way to represent a cell, but it is very awkward to do a very simple backtracking solver as when you try to loop over the possible values you have to use NonZeroU<*>::new or NonZeroU<*>::new_unchecked.

Nemo157 · April 23, 2023, 11:57am

I assume what you're after is Range<NonZeroU32>: Iterator etc. to allow for x in (const { NonZeroU32::new(1).unwrap() }..const { NonZeroU32::new(5).unwrap() }) { ... }?

This is controlled via a blanket impl impl Iterator for Range<impl Step>, so what would be required is impl Step for NonZeroU32 etc. That trait seems trivial to implement for the nonzero types, I found one previous request to add it, this probably just requires someone to create a draft impl to make sure it's possible and file an ACP to get the process started.

github.com/rust-lang/rust

[ER] NonZeroX Step and better constructors

opened 11:00AM - 08 Jun 20 UTC

leonardo-m

T-libs-api C-feature-request

It could be nice to have std::iter::Step for the NonZeroX numbers, so in this co…de instead of having about 1000 unwrap: ```rust fn main() { use std::num::NonZeroUsize; let nz = |x| NonZeroUsize::new(x).unwrap(); for i in 1 .. 1_000 { println!("{:?}", nz(i)); } } ``` You only need two: ```rust fn main() { use std::num::NonZeroUsize; let nz = |x| NonZeroUsize::new(x).unwrap(); for i in nz(1) .. nz(1_000) { println!("{:?}", i); } } ``` If also a const-generics-based constructor is added to stdlib then the number of run-time unwraps goes to zero (the two panics become compile-time): ```rust fn main() { use std::num::nonzero_usize; for i in nonzero_usize::<1>() .. nonzero_usize::<1_000>() { println!("{:?}", i); } } ``` A further improvement should come from const generics of arbitrary type (currently not allowed): ```rust fn main() { use std::num::nonzero_usize; for i in nonzero::<1_usize>() .. nonzero::<1_000>() { println!("{:?}", i); } } ```

Nemo157 · April 23, 2023, 11:59am

Actually, I forgot to search the libs-team repo too, there is an open ACP already

github.com/rust-lang/libs-team

Implement Step for NonZeroUxx

opened 09:11AM - 30 Oct 22 UTC

SOF3

T-libs-api api-change-proposal

# Proposal ## Problem statement Ranges of non-zero **unsigned** intege…rs does not contain zero, and should be step-able. ## Motivation, use-cases I want to iterate over a `Range<NonZeroUsize>`. ## Solution sketches It might be tricky to implement `backward_checked` properly since we cannot guarantee that the input `usize` is less than `start`. It is also inconsistent that NonZeroIxx are not implemented. ## Links and related work ## What happens now? This issue is part of the libs-api team [API change proposal process]. Once this issue is filed the libs-api team will review open proposals in its weekly meeting. You should receive feedback within a week or two. [API change proposal process]: https://std-dev-guide.rust-lang.org/feature-lifecycle/api-change-proposals.html

scottmcm · April 23, 2023, 11:16pm

Hmm, an interesting consequence of this is that we could have RangeInclusive<NonZeroUsize>: ExactSizeIterator even though RangeInclusive<usize>: !ExactSizeIterator.

jalil-salame · April 24, 2023, 1:15pm

Thanks for the replies, I've turned on notifications for those issues and if I have time I will look over the process to maybe submitting a pull request about it, it seems fairly straightforward to implement.

If you have the time to elaborate, how did you find these issues? I totally missed the libs-team repo, but I thought I did a through search of the rust issues...

Nemo157 · April 24, 2023, 5:40pm

Looks like the searches I used were:

(Most of the time when looking for something like this I remove the is:issue is:open default to see if there were any relevant PRs or closed issues, then it's just a matter of being able to quickly skim the far too many results that gives).