Method of same name is shadowing a property in Swift 3


(Jens Alfke) #1

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


(Hooman Mehr) #2

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


(Jens Alfke) #3

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?


(Jens Alfke) #4

I have now: https://bugs.swift.org/browse/SR-2633

—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?


(Zhao Xin) #5

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.

—Jens

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users


(Jens Alfke) #6

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.