[swift-evolution] [pitch] Comparison Reform
xiaodi.wu at gmail.com
Sat Apr 15 17:28:21 CDT 2017
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
> 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...
More information about the swift-evolution