Safe const NonZero values

1

I'm finding myself writing a LOT of unsafe { NonZero::new_unchecked(1) } and similar lines. It seems like language updates facilitate a more compact syntax such as NonZero::new_const::<1>(). This seems like it could be implemented along the lines of

impl NonZero<u8> {
    const fn new_const<const N: u8>() -> Self {
        const {assert!(N != 0, "can't initialize NonZero value as 0"); }
        Self(N)
    }
}
2

I think this will be better solved by pattern types:

impl NonZeroU8 {
    pub fn from(n: u8 is 1..) {
        Self(n)
    }
}

In the meantime you may as well use NonZero::new(1).unwrap() because it will easily optimize away.

Edit: I see unwrap is still const-unstable, in const contexts new_unchecked will still be necessary.

3

You can use match and panic!()/unreachable!() in the None branch, which is possible on stable since 1.57

let one = const {
    match NonZeroU8::new(1) {
        Some(one) => one,
        None => unreachable!(),
    }
};
8 Likes
4

You can eliminate the repetitiveness by defining a function that does it.

The best way to handle this in the language would be to allow literals like 1 to have this type too. Even better if any custom types could have integer literals.

2 Likes
5

Of course, once we have pattern types we won't really need NonZeroU8 any more :upside_down_face:

1 Like
6

Pattern types is something that may or may not exist, and if it ends up stabilized it may be 10 years from now.. this API is something that can be added right now

And also: NonZero may well become deprecated once pattern types is stabilized!

3 Likes
7

There are interesting rules around pattern-restricted types that can result in u8 is 1.. and NonZeroU8 behaving differently if we want the intuitive subtyping rules to work out. So I don't think NonZero<_> will end up fully deprecated, just used in APIs a lot less.

1 Like
8

What would be really awesome is if the compiler had support for using the literal syntax so there's no need to define any sort of special constructor method whose need might be obviated by future compiler features like const unwrap():

const FOO: NonZero<u8> = 42;

Something like this would cause a compile error:

const FOO: NonZero<u8> = 0;

Not sure what blocked this sort of thing before with e.g. NonZeroU8 but with NonZero<T> it seems there's now at least only one type that needs some magic compiler assistance.

6 Likes
9

The primary thing is that type inference/fallback around the {integer} placeholder inference type is extremely ad-hoc and hacky, and adding new types into the set is likely to cause inference breakage, that breakage has reasonable potential to be widespread, and there's no good way to keep it from immediately being stable (as trait impls generally always are).

(E.g. you can sometimes call methods directly on {integer}, if they come from a trait. If the method is shadowed by an inherent method, calling it twice can call either method depending on context, without any compiler warnings. It's a textbook example of spooky action at distance.)

There's interest in migrating it to a trait, but removing the pile of special cases quickly runs headfirst into the thorny problem that is defaults that affect type inference. The discussion on the old tracking issue covers some of the hairy questions that led to closing that issue.

AIUI this is one of the things that the new inference engine / trait solver should unblock, and everyone with the ability to do so is focused on moving that work forward in leu of extending the current system.

3 Likes
10

I tried this a couple years ago. It's easier said than done, unfortunately.

1 Like
11

more important than compactness is saftey. NonZeroU8::new_unchecked(0) is immediate undefined behavior, even though most users wouldn't mind the additional cost of a check+panic.

const functions have become a lot less limited than they were a few years ago.

12

The limitations of const was hardly an issue then (and it hasn't improved here, as const traits are needed). It was a matter of being able to implement it on the language side of things.

13

why do you need const traits? why not just do a zero check then call new_unchecked?

14

It was intended to be a general purpose mechanism to avoid adding roughly a dozen new lang items.

1 Like
15

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