You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unfortunately, given how segments are represented as closed-open intervals, the maximum value cannot be included in the segment. I have not yet determined a simple, consistent way to address this. For now, this is not a main concern for me as the current implementation fits my needs well enough.
Workarounds:
For any of the numeric types, the maximum value should just not be considered a valid value. For example, valid Unicode is from U+0000 to U+10FFFF. Therefore, when representing Unicode using u32, it is safe to ignore 0xFFFFFFFF.
Unfortunately, given how segments are represented as closed-open intervals, the maximum value cannot be included in the segment. I have not yet determined a simple, consistent way to address this. For now, this is not a main concern for me as the current implementation fits my needs well enough.
Workarounds:
U+0000
toU+10FFFF
. Therefore, when representing Unicode usingu32
, it is safe to ignore0xFFFFFFFF
.closed
andall
--coming soon with It doesn't make sense to have enumerated types implementnum::One
,num::Zero
, orstd::ops::Add
. #1), simply append anUnused
(or similar) variant to the list of variants. Then, the default#[derive(Ord, PartialOrd)]
will have that as the maximum value.The text was updated successfully, but these errors were encountered: