> On Apr 22, 2017, at 4:14 PM, Dave Abrahams <dabrah...@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_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
