3 ms·

Rust has an interesting optimization for Option<T> when T has enough "room" for encoding a marker for "None": https://google.github.io/comprehensive-rust/std/bo

Rust has an interesting optimization for Option<T> when T has enough "room" for encoding a marker for "None": https://google.github.io/comprehensive-rust/std/box-niche.html https://google.github.io/comprehensive-rust/std/box-niche.ht... e.g. Option<NonZeroU64> is effectively encoded and operated on as u64, but it gives the type system a way to make sure you correctly handle the case where "0" means something special for you

chrismorgan 4y ago
Just a pity we currently only have number types with the niche at zero; something like NonMaxU32, which represents numbers in the range [0, 2³² − 2], would be useful at least as often, leaving 0xffffffff available for niche optimisations like Option::<NonMaxU32>::None. NonMinI32 could also be interesting as a symmetrical number type, representing [−2³¹ + 1, 2³¹ − 1] and leaving the bit pattern 0x80000000 for niche optimisations.
- tialaramex 4y ago
  Eventually it will be possible to write new types like this in stable Rust, the current approach is Pattern Types. Today you can do this in nightly Rust, using a deliberately permanently unstable attribute, that's what my nook crate does to produce e.g. BalancedI8 which is a signed byte from -127 to 127. It will be nice when some day Pattern Types, or an equivalent are stabilized.
- dathinab 4y ago
  When there was a lot of discussions about niche optimizations and integers that if we had const generics we could have `NonXXX` types which use const generics to specify the niche. But back then we hadn't had const generics and it was time wise too far off to wait for const generics in anyform (including unstable rustc internal only usage of it). So if now that we have const generics somone sits downs discusses the technical details on zulip, then writes a RFC and then writes an implementation we theoretically could have it soon. Through I'm not sure how easy/hard the implementation part would be. Some problems to discuss for standardization would be: - is there any in progress work, overlapping RFC etc. (Idk. there should be older in progress work, but someone might be working on it right no idk). There could also be work on a more generic niche handling code which would happen to also cover this idk. - should multiple niches be handled and if so how with which limitations (there are no variadic generic and ways to emulate them like through type nesting likely wouldn't have pef and complexity problems) - can it be usefull for outside of optimizations to have e.g. a range limited integer - if the gap is big enough (i.e. u32 limited to a hypothetical u24), should it interact with packed representation - is there any risk of it being confusing/unexpected (should not be the case, but still needs to be evaluated) EDIT: There seem to be unstable following attributes: #[rustc_nonnull_optimization_guaranteed] #[rustc_layout_scalar_valid_range_start(...)] #[rustc_layout_scalar_valid_range_end(..)]
- kibwen 4y ago
  I strongly suspect that niches will be stabilized for user-defined types someday. Unlike some other features (e.g. specialization) where there are open questions about how the feature could possibly work, niches are well-understood and mostly just need somebody to champion them.

chrismorgan 4y ago

Just a pity we currently only have number types with the niche at zero; something like NonMaxU32, which represents numbers in the range [0, 2³² − 2], would be useful at least as often, leaving 0xffffffff available for niche optimisations like Option::<NonMaxU32>::None. NonMinI32 could also be interesting as a symmetrical number type, representing [−2³¹ + 1, 2³¹ − 1] and leaving the bit pattern 0x80000000 for niche optimisations.

tialaramex 4y ago
Eventually it will be possible to write new types like this in stable Rust, the current approach is Pattern Types. Today you can do this in nightly Rust, using a deliberately permanently unstable attribute, that's what my nook crate does to produce e.g. BalancedI8 which is a signed byte from -127 to 127. It will be nice when some day Pattern Types, or an equivalent are stabilized.
dathinab 4y ago
When there was a lot of discussions about niche optimizations and integers that if we had const generics we could have `NonXXX` types which use const generics to specify the niche. But back then we hadn't had const generics and it was time wise too far off to wait for const generics in anyform (including unstable rustc internal only usage of it). So if now that we have const generics somone sits downs discusses the technical details on zulip, then writes a RFC and then writes an implementation we theoretically could have it soon. Through I'm not sure how easy/hard the implementation part would be. Some problems to discuss for standardization would be: - is there any in progress work, overlapping RFC etc. (Idk. there should be older in progress work, but someone might be working on it right no idk). There could also be work on a more generic niche handling code which would happen to also cover this idk. - should multiple niches be handled and if so how with which limitations (there are no variadic generic and ways to emulate them like through type nesting likely wouldn't have pef and complexity problems) - can it be usefull for outside of optimizations to have e.g. a range limited integer - if the gap is big enough (i.e. u32 limited to a hypothetical u24), should it interact with packed representation - is there any risk of it being confusing/unexpected (should not be the case, but still needs to be evaluated) EDIT: There seem to be unstable following attributes: #[rustc_nonnull_optimization_guaranteed] #[rustc_layout_scalar_valid_range_start(...)] #[rustc_layout_scalar_valid_range_end(..)]
kibwen 4y ago
I strongly suspect that niches will be stabilized for user-defined types someday. Unlike some other features (e.g. specialization) where there are open questions about how the feature could possibly work, niches are well-understood and mostly just need somebody to champion them.