upvote
Steve wasn't talking about unsafe. He was talking about being able to mint your own non-enum types with user defined niches.

Rust provides for example NonZeroU8 which is an 8-bit unsigned integer that's never zero, leaving it with 255 possible values and a convenient niche. You cannot make one of these yourself directly, because the mechanism used by Rust itself is a deliberately perma-unstable compiler-only proc macro which says "Hey compiler, I promise I only ever use bit patterns 0x01 through 0xFF inclusive".

Today you can either - hide a NonZero type inside your type and use that to get the niche, or, use an enum itself which automatically knows ever pattern it didn't use is a niche. In the future a hypothetical "Pattern Types" feature would let you make such types yourself as easily as Rust does

Personally I would like to make a Balanced set of types, like BalanacedI8 (the 8-bit integers except the most negative, so -127 to +127 inclusive) because I think lots of people have a use for types like i8 or i32 but don't need their unbalanaced most-negative value and could re-purpose it this way. And you can make such types... indeed I have... but it's only really practical in unstable Rust.

reply
Arbitrary subranges of int types were available in Ada for over 40 years via static enforcement via Spark and compilers were able to optimize them nicely.

For a system language I wish Rust would support such things rather than coming with NonZero hacks.

reply
This is called "pattern types" in Rust land, as your parent mentioned, and is exactly the kind of work being talked about.

NonZero isn't a hack: it's an example of a common pattern. If pattern types were available today, you'd still want NonZero, as an example of a pretty standard pattern.

The idea is, as always: prove out the specific version, then generalize.

reply
Can it do holes like this?

  (typep 3 '(or (integer 0 10) (integer 50 100)));; => T
reply
You can use a "subtype predicate" for this: https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Devel...
reply
Might be less efficient, no? At least in CL (https://www.lispworks.com/documentation/HyperSpec/Body/t_sat...) this is the case, that static type analysis isn't clever enough to work with predicate based types.
reply
I don't know enough about the details to speak to it.
reply