Tracking Issue for NonMin and NonMax types.

Feature gate: #![feature(nonmin_nonmax_types)]

This is a tracking issue for https://github.com/rust-lang/libs-team/issues/721

NonMin and NonMax are niche types, like NonZero, that provide niches at T::MIN and T::MAX respectively.
They are akin to NonZero in API, minus the individual aliases.

Public API

As this API is implemented for many distinct types, I'm opting to only show the impls for NonMin<isize> for demonstration purposes.
The surface area for NonMin and NonMax are identical and their behavior only differs in niche location.

// Constrained such that T is one of i8, i16, i32, i64, i128, or isize.
/// A value that is known to not be its minimum.
/// This enables some memory layout optimization. For example, `Option<NonMin<u32>>` is the same size as `u32`.
struct NonMin<T: NonMinPrimitive>;

// Constrained such that T is one of u8, u16, u32, u64, u128, or usize.
/// A value that is known to not be its maximum.
/// This enables some memory layout optimization. For example, `Option<NonMax<u32>>` is the same size as `u32`.
struct NonMax<T: NonMaxPrimitive>;

impl NonMin<isize> {
   const MIN: Self;
   const MAX: Self;
   const BITS: Self;
   
   pub const fn get(self) -> isize;
   pub const fn new(n: isize) -> Option<Self>;
   pub const unsafe fn new_unchecked(n: isize) -> Self;
   
   
   // Intent is to match the current NonZero surface area when sensible.
   // To avoid leaving an unreviewable spill of information, I will not list every method,
   // in favor of discussing them here verbally.
   // 
   // Input from https://github.com/rust-lang/libs-team/issues/721#issuecomment-3725065768
   // is to be accounted for, a lot of functions only ever shrink their input around zero
   // and will not produce the min or max value, making them obvious candidates to provide.
   //
   // The checked_ family of math functions (add, sub, mul, div) will exist, but
   // the overflowing_/wrapping_ family is not useful by definition, as they allow an operation to
   // wrap to the MIN or MAX of a type.
   // 
   // saturating_ is possible, but would need to be falliable as it can only saturate in 
   // one direction, or alternatively all three questionable families could be made to work 
   // by defining them as working within the valid space of the type.
   // 
   // The methods behind the nonzero_bitwise and nonzero_ops feature flags would also be sensible.
}

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• ACP: https://github.com/rust-lang/libs-team/issues/721
• Implementation: #...
• Final comment period (FCP)^1
• Stabilization PR

Maintenance remarks

Unresolved Questions

• What action should be taken for overflowing_, wrapping_, and saturating_?