Interval of Float are not nice to have: we already have!
Here are 4 propositions that I wanted to put on the table:
1) It is recommended to avoid using Interval of Float, because they will have pitfalls, expecially if you have naive expectations.
2) It is void to try masking the inexact nature of Float by partial waorkarounds
3) It is recommended to provide implementation robust to inexact arithmetic, and avoid adding more pitfalls than necessary.
4) It is recommended to teach the limitations.
Known failures is somehow a way to document that.
But adding some code to explicitly forbid Interval of Float, no, that's something I would avoid!
IMO, it is a wrong answer to 1).
It's like wanting to over-protect the user because we presume he is dumb and cannot learn anything complex.
That's not the spirit of Smalltalk IMO. We must make simple things simple, and open the possibility to make more complex things.
We must not be castrating but inviting and teaching.
After all, making mistakes is a good way to learn, we must not try to prevent that ;)
IMO the right answer is 4).
Float are full of pitfalls. But we don't forbid Float, do we? They have too much practical value, and we'd better learn to use them.
Maybe Interval of Float has less value than Float, but it's a bit like saying that oranges have less value than citruses ;)
They have not much value in the core image, but you cannot presume they will never have.
Try to make a LogarithmicInterval without Float for example... Analysis of systems in frequency domain requires such species!
The dicussion I wanted to open was about 2) and 3).
In the past, some wanted to reduce the surprising behavior by masking the inexact nature of Float arithmetic
(round to nearest in the best case, uncontrolled accumulation of rounding errors in the worse one).
This was done by encoding arbitrary comparison thresholds in some methods.
But this lead to more surprising behavior in the end, and it is enforcing wrong expectations.
That's what I tried to document with the new failing tests.
So the first thing is that I wanted to remove those workarounds, and reveal the true nature of Float, not masking it.
They make things worse IMO.
The second thing is that there are other naive implementations of Interval methods that won't work with inexact arithmetic.
But with some care, we can rewrite those to also behave better with inexact. The question if it is worth or not.
It's a trade off between complexity and utility.
That's why it is in the inbox, and we can decide that they are nice to have or overkill for too few value.
We can also postpone the decision with known failures, fix later, or delegate to an external package...