>
>> I think consideration should be given to a design that achieves a
>> user-facing but not onerous differentiation between level 1 and level 2
>> equality. However, the only one I can think of is essentially a different
>> shade of the `PartiallyComparable` alternative already outlined in the
>> document.
>
> I am *deeply* opposed to such a protocol. It is purely syntactic in
> nature and thus useless for correctly constraining generic algorithms.
> People will use it anyway, resulting in algorithms that statically
> accept, but are incorrect for, floating point. In my opinion there's
> only one feasible answer that doesn't use the static/dynamic distinction
> we've proposed: throw IEEE semantics under the bus, making it available
> only under a different syntax.
>
> This would be a drastic move whose primary downside is that floating
> point code ported from C would need to be carefully audited and may
> become less easy to read. But at least it would be viable.
Yeah, I think it should really be considered. An IEEEComparable protocol,
defining methods such as “isEqualTo”, “isLessThan”, etc would make the
distinction clearer.
And, as you said, not many people really know or care about the IEEE comparison
special cases. It’s a bit of an expert field. Is it that bad to ask experts who
explicitly care about the order between +/- 0 or different NaNs to use a
special function for that behaviour?
I suppose it needs to be weighed up with something like: (number of people
ignorant of the difference) x (probability of unexpected result) x
(significance of unexpected result, if estimable).
How often do non-floating point experts even use FloatingPoint as a protocol
(as opposed to Float/Double)?
- Karl
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
