Feathers: NumberInputWrap on HardLimit should wrap *after* range end

[kfc35]

Objective

• Address this comment Feathers HardLimit and SoftLimit now accept a RangeInclusive #25237 (comment)

this is not right for a inclusive range, the range of values would be r.end() - r.start() + 1

Solution

• Wrap happens after the inclusive endpoint. This means that, for example, an i32 number input with a HardLimit of 0..=10 will cycle when scrubbed to “11” instead of “10”
• For F32, we use next_up() instead of incrementing by 1 since it’s the next f32 number after the range end that should wrap over to the beginning.

Testing

• cargo run --example feathers_number_input --features=“bevy_feathers"

[viridia]

I don't think this is the behavior we want.

The original use case was to wrap when an input went from -PI..PI. In this case, the value never actually reaches PI, so even though the range is inclusive, when wrapping is enabled it's in effect half-open.

I don't think that changing the input range to go from -PI to PI.next_down() makes things clearer, as now the span of the range no longer matches the wrapping modulus.

We did flirt with supporting half-open ranges as well as inclusive ranges, but other than the wrapping case it's hard to think of a realistic use case for it, and it makes the slider code more complex.

[viridia]

A few more thoughts:

As you know, I tend to lean on the side of practicality over purity.

From a mathematical purist point of view, the concept of rem_euclid dovetails exactly with half-open intervals. Using them with inclusive ranges is a mismatch.

However, for non-wrapping inputs, inclusive ranges is almost always what you want: whether we are talking about alpha, roughness, metallicity, or just about any other bounded quantity, the legal values are min to max, inclusive.

One solution is to simply define the problem away by fiat, and document it in the description of the NumberInputWrap option.

Another solution is to go back to the earlier PR which allowed an exclusive range option. However, this makes the trait more complex, and in the non-wrapping case opens up a space of possible configurations that will likely never be explored (such as half-open ranges which are open at the end).

[kfc35]

One solution is to simply define the problem away by fiat, and document it in the description of the NumberInputWrap option.

This one is the most appealing to me. I didn’t really like making this PR and I think you clarified for me that the reason I was feeling weird is that wrapping really makes the most sense when the end of the range is interpreted as exclusive.

I'm thinking I will close this and just make a doc change to the effect of “When used in conjunction with Hard Limit, the range end becomes exclusive", but will leave this open for 24 hours in case anyone else has any other comments / thoughts.