> On Dec 14, 2016, at 09:54, Jordan Rose <[email protected]> wrote: > > >>> On Dec 13, 2016, at 20:43, David Sweeris via swift-evolution >>> <[email protected]> wrote: >>> >>> >>> On Dec 13, 2016, at 9:51 AM, Chris Lattner <[email protected]> wrote: >>> >>> On Dec 12, 2016, at 6:58 PM, David Sweeris via swift-evolution >>> <[email protected]> wrote: >>>>> On Dec 12, 2016, at 16:15, John Holdsworth via swift-evolution >>>>> <[email protected]> wrote: >>>>> >>>>> I’d like to raise again the idea of optionality when referencing a key or >>>>> calling a function could be possible using a ? i.e instead of >>>>> >>>>> let a = key != nil ? dict[key] : nil >>>>> >>>>> you could just write: >>>>> >>>>> let a = dict[key?] >>>>> >>>>> or even >>>>> >>>>> let a = func( arg: argumentThatMayBeNull? ) // not called if argument is >>>>> nil >>>> >>>> The first part is pretty easy to add in an extension: >>>> >>>> extension Dictionary { >>>> subscript(_ key:Key?) -> Value? { >>>> return key != nil ? self[key!] : nil >>>> } >>>> } >>>> >>>> At least I think that works... I'm on my phone so I can't test it. >>> >>> You can do something like this, but I’d recommend labeling the subscript. >>> The problem comes up when you have a dictionary that has an optional key: >>> When you use “myDict[nil]”, you may get one or the other, but you probably >>> mean one specifically. >> I don’t think that’s an issue in the stdlib, because `Optional` doesn’t >> conform to `Hashable` and, AFAIK, no other stdlib types conform to >> `ExpressibleByNilLiteral`. Custom types could conform to both, though, and >> according to a playground, that does indeed lead to some confusing code: >> struct Foo : ExpressibleByNilLiteral, Hashable {...} >> extension Dictionary { subscript(_ key:Key?) -> Value? { return key != nil ? >> self[key!] : nil } } >> var bar = [Foo:Int]() >> bar[nil] //calls `Foo.init(nilLiteral:())`, and tries to look up the new >> `Foo` in `bar` using the stdlib's subscript >> bar[nil as Foo?] //passes `Optional<Foo>.none, which uses the extension's >> subscript > > I wouldn't be surprised if there's a proposal to make Optional conditionally > conform to Hashable if/when we get conditional conformances.
Probably, yeah... I'll be curious as to how they propose we prevent collisions between Optional<T>.none.hashValue and any given T's hash value. - Dave Sweeris
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
