As I see it, this is serious bug. In Swift 3.0, parameter labels (or lack of them) are supposed to be a part of the function name. Otherwise, the two `key` definitions would create a name collision and should have been rejected in the first place. This should not happen, because only `key(at:)` should be treated as a method pointer and not `key`. Even the following example:
protocol QueryRow { var key: Any { get } func key(_ index: UInt) -> Any? } should not create a collision as method pointer now is `key(_:)` and not `key`. I guess the reason this is happening is some attempt at backward compatibility, but this is clearly causing a serious bug. Have you reported it? > On Sep 13, 2016, at 1:13 PM, Jens Alfke via swift-users > <swift-users@swift.org> wrote: > > One of my co-workers just noticed a problem with the (bridged) API of our > Objective-C framework, when used from Swift 3 (but not earlier). We have a > class CBLQueryRow that includes the following: > > @property (readonly) id key; > - (nullable id) keyAtIndex: (NSUInteger)index; > > In Swift this becomes > open var key: Any { get } > open func key(at index: UInt) -> Any? > > The problem is that any reference to `key` now seems to refer to a pointer to > the method, not to the property, leading to compiler diagnostics like the > following (where `row` is a CBLQueryRow): > > TaskListsViewController.swift:95:40: warning: cast from '(UInt) -> Any?' to > unrelated type 'String' always fails > cell.textLabel?.text = row.key as? String > ~~~~~~~ ^ ~~~~~~ > That’s a warning not an error, but obviously at runtime the `as?` would > always fail and result in nil. > > This is rather bad for us, since the `key` property is a crucial part of the > API, while the `key()` method that pre-empts it is obscure and little-used. > > I can reproduce this in a playground in Xcode 8 like so: > > protocol QueryRow { > var key: Any { get } > func key(at index: UInt) -> Any? > } > > var row: QueryRow > > row.key as? String > In addition to the valid error about `row` being uninitialized, I also get > the cast failure. > > What’s the best workaround for this? > > —Jens > _______________________________________________ > swift-users mailing list > swift-users@swift.org > https://lists.swift.org/mailman/listinfo/swift-users
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users