On Sat, Apr 15, 2017 at 5:25 PM, Karl Wagner via swift-evolution < [email protected]> 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.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
