[swift-evolution] [pitch] Comparison Reform
mayoff at dqd.com
Tue Apr 25 09:00:12 CDT 2017
On Mon, Apr 24, 2017 at 11:44 PM, David Waite via swift-evolution <
swift-evolution at 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.
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution