[swift-evolution] [pitch] Comparison Reform

[David Sweeris]

> On Apr 22, 2017, at 4:14 PM, Dave Abrahams <dabrahams at apple.com> wrote:
> 
> 
> on Sat Apr 22 2017, David Sweeris <davesweeris-AT-mac.com> wrote:
> 
>> Maybe we should make Float/Double conform to
>> "IEEE754Comparable"/"IEEE754Equatable" instead of
>> "Comparable"/"Equatable". Then it's all a moot point since floating
>> point types wouldn't end up in the same generic functions as other
>> comparable types.
>> 
>> (Not sure if I'm serious)
> 
> Do you want to ban 
> 
>  Dictionary<Float,String>
> 
> ?  That would be one consequence.

I started writing a big long reply last night, but I accidentally deleted the draft instead of saving it. Oh well, it was kinda rambly anyway. Here're my two (and a half?) main points:

1.a) No
1.b) Although maybe we should, since this is the current behavior in playgrounds:
var dict = [Double:String]()
dict[.nan] = "Foo"
dict.description // "[nan: "Foo”]” Yay!, it was inserted!
dict[.nan]?.description // “nil" Wait, what?
dict[.nan] = "Bar"
dict.description // "[nan: "Foo", nan: "Bar”]” Hey, how come two values have the same key?
dict[.nan]?.description // “nil" And why can’t I retrieve either of them?
let values: [String?] = dict.keys.map { dict[$0]?.description }
values.description // "[nil, nil]” I can’t even use the keys given by the dictionary itself to get my values?!?
2) Maybe it would be helpful to think of Float and Double as sorta being their own Optional type with an extra payload to let a pseudo-“.none" explain why it's not a valid value. I’m not suggesting that we actually redefine Double as “Optional<Real64>” (even if we could get the extra payload), but if we think of them that way, it might simplify how we approach this.

- Dave Sweeris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170423/e08e0d2b/attachment.html>