Impl Range and RangeInclusive for NonZeroU<*>

language design
1

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.

1 Like
2

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.

2 Likes
3

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

2 Likes
4

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

3 Likes
5

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...

6

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).

7

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.