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.
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.
No; I’m not a Swift expert, and am not following the 3.0 transition closely enough to tell whether this is a bug or just some unfortunate but intentional fallout from the transition.
—Jens
···
On Sep 13, 2016, at 3:13 PM, Hooman Mehr <hooman@mac.com> wrote:
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?
You said your issue only existed in Swift 3. However, you issue still
exists in Xcode 7.3.1, which uses Swift 2.2. I tested your playground code.
protocol QueryRow {
var key: Any { get }
func key(at index: UInt) -> Any?
}
var row: QueryRow
row.key as? String
Zhaoxin
···
On Wed, Sep 14, 2016 at 7:08 AM, Jens Alfke via swift-users < swift-users@swift.org> wrote:
On Sep 13, 2016, at 3:13 PM, Hooman Mehr <hooman@mac.com> wrote:
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?
No; I’m not a Swift expert, and am not following the 3.0 transition
closely enough to tell whether this is a bug or just some unfortunate but
intentional fallout from the transition.
Interesting. I think the difference is that prior to Swift 3, the original Objective-C method was translated into Swift differently — I believe it came out as keyAtIndex() — so it didn’t trigger this name collision issue.
—Jens
···
On Sep 13, 2016, at 4:47 PM, Zhao Xin <owenzx@gmail.com> wrote:
You said your issue only existed in Swift 3. However, you issue still exists in Xcode 7.3.1, which uses Swift 2.2. I tested your playground code.