[swift-evolution] [pitch] Comparison Reform

[Xiaodi Wu]

On Sat, Apr 15, 2017 at 5:25 PM, Karl Wagner via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
> 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)?
>

Such a design would also require every port of numeric algorithms that use
the concrete types themselves (Float and Double) to use .isEqualTo, etc.,
or else silently break. It would make Swift a non-starter for almost any
serious numeric work that uses floating point types.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170415/1e94f56a/attachment.html>