Improve Foundation overlay to handle bridging subscripts and dictionary literals.

[jckarter]

SE-0072 took implicit bridging conversions away, which regressed the ability to express NSDictionaries as dictionary literals and index them using literal keys. Address this by changing the signature of init(dictionaryLiteral:) to use Hashable and Any, and by replacing the subscript from Objective-C with one using _Hashable that does the bridging on the user's behalf. This largely restores the QoI of working with NS collections.

[jckarter]

@swift-ci Please smoke test

[jckarter]

@parkera @phausler What do you think of these changes? There's a bit of an unfortunate tradeoff in our type system now between enforcing NSCopying conformance for classes and admitting Hashable value types that are naturally copyable and bridge to NSCopying objects.

[gribozavr]

Please add a FIXME(ABI) with a note that it should become a generic subscript.

[phausler]

Does this cause any poor interaction with CoreData or other subclassers of NSDictionary? I think the subscript accessors being clean are more important than enforcement of NSCopying (that already is a buyer be aware contract in swift as it is).

Also does this properly work for subclasses of NSDictionary made in Swift being handed off into ObjC (subscript is very often accessed in frameworks)

[jckarter]

@phausler Do any of those clients override objectForKeyedSubscript: or setObject:forKeyedSubscript:? As long as subclassers override objectForKey: and setObject:forKey: (which is the right thing to do AIUI), there shouldn't be a bad interaction.

[jrose-apple]

I'm not especially happy with Swift subclassers not being allowed to override the subscript, but as Philippe points out they probably shouldn't be using that as the override point anyway.

[jckarter]

@swift-ci Please smoke test

[jckarter]

@jrose-apple @gribozavr @phausler I tried a different approach that doesn't rely on final, _Hashable, or hiding the native objectForKeyedSubscript: implementation (since doing so also broke AnyObject dynamic lookup for subscripts). How does this look?

[jckarter]

@rudkx @DougGregor Somehow, the overlay changes here trigger a change in behavior in Swift.Dictionary that causes the subscript operator to become ambiguous in validation-test/stdlib/Dictionary:

/Users/jgroff/src/s/swift/validation-test/stdlib/Dictionary.swift:3203:4: error: ambiguous reference to member 'subscript'
  d["hello"] = 17
  ~^~~~~~~~~
Swift.Dictionary:261:12: note: found this candidate
    public subscript(position: DictionaryIndex<Key, Value>) -> (key: Key, value: Value) { get }
           ^
Swift.Dictionary:306:12: note: found this candidate
    public subscript(key: Key) -> Value? { get set }
           ^
<unknown>:0: note: found this candidate
Swift.Dictionary<Key, Value>:3:12: note: found this candidate
    public subscript(key: _Hashable) -> Value? { get set }
           ^
Swift.Collection:25:12: note: found this candidate
    public subscript(bounds: Range<Self.Index>) -> Slice<Self> { get }
           ^
Swift.Indexable:23:12: note: found this candidate
    public subscript(bounds: ClosedRange<Self.Index>) -> Self.SubSequence { get }
           ^
Swift.Indexable:23:12: note: found this candidate
    public subscript(bounds: CountableRange<Self.Index>) -> Self.SubSequence { get }
           ^
Swift.Indexable:45:12: note: found this candidate
    public subscript(bounds: CountableClosedRange<Self.Index>) -> Self.SubSequence { get }
           ^

[jrose-apple]

Why does this need to be @objc at all?

[jrose-apple]

…oh, for overriding purposes in Swift today.

[jckarter]

That's the only way we get overrideable methods in extensions right now. Without the custom selectors this would collide with the subscript methods from Cocoa.

[jrose-apple]

Maybe a FIXME, then?

[jrose-apple]

What's the advantage of using Any over _Hashable in the new approach? Ambiguity with NSCopying?

[jckarter]

That's one reason. _Hashable also (a) isn't @objc-representable, (b) isn't meant to be long-term API or ABI. Since it's not providing much real static safety for these operations (and NSDictionary's objectForKey: accepts id in ObjC anyway) Any seems like a more practical choice.

[rudkx]

@jckarter I'll try to look at this next.

[jckarter]

@swift-ci Please smoke test and merge