On Mon, Apr 24, 2017 at 11:44 PM, David Waite via swift-evolution < swift-evolution@swift.org> wrote:
> I still think this is a naming conflict more than anything else. > > The first expectation is that equatable and comparable provides strict > equality and strict total ordering, and that those are exposed via > operators. The other expectation is that floating point abides by the IEEE > rules which have neither of these, and are exposed via operators. > > Either: > 1. the operators need to do different things in different contexts > 2. we need different methods/operators to indicate these different concepts > 3. Equatable and comparable need to be altered to no longer require strict > equality and strict total ordering (and all generic algorithms based on > equatable/comparable need to be checked that they still work) > 4. floating point numbers need to explicitly not be equatable/comparable > to prevent their usage in generic algorithms requiring strict behavior. > 5. We break away from IEEE behavior and provide only strict equality and > strict total ordering > > (I tried to sort these roughly in order of feasibility) > > Are there any other options? > Have Double and Float do #5, and new types IEEEDouble and IEEEFloat implement IEEE behavior and not be suitable for use with generic algorithms when NaNs are present.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
