You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a property and a method with the same name exist, then (at least in one circumstance) the compiler interprets a reference to the property as a reference to the method, or rather as a pointer to the method. I can reproduce this in a playground in Xcode 8 like this:
{{
protocol QueryRow {
var key: Any { get }
func key(at index: UInt) -> Any?
}
var row: QueryRow
row.key as? String
}}
This obviously produces an error that 'row' hasn't been initialized yet. But there's also a warning: "cast from '(UInt) -> Any?' to unrelated type 'String' always fails". This implies that the compiler treated `.key` as a reference to the method, not the property. I have not been able to figure out a syntax to use to work around this and get a reference to the property.
This is causing trouble in the real world, because this situation manifests in the (bridged) API of our Objective-C framework Couchbase Lite, when used from Swift 3 (but not earlier). We have a class CBLQueryRow that includes the following:
(nullable id) keyAtIndex: (NSUInteger)index;
}}
In Swift 3 this becomes
{{
open var key: Any { get }
open func key(at index: UInt) -> Any?
}}
which triggers this problem. Here's an actual warning message from the Swift 3 compiler in Xcode 8.0:
{{
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 our API, while the `key()` method that ends up hiding it it is obscure and little-used.
The text was updated successfully, but these errors were encountered:
FYI, the initial discussion of this is in a thread on swift-users titled "Method of same name is shadowing a property in Swift 3", starting on 9/13/16 (today).
This is not actually shadowing. What's happening here is that both the property and method are considered by the type checker and it considers the method to be the better choice based on it's current scoring model.
That seems pretty broken considering that the conditional cast from Any to String is a far more reasonable choice than a conditional cast from a function type to a String.
Environment
Xcode 8, macOS 10.12
Additional Detail from JIRA
md5: 1dafeda3b6dbaefd94365ed469dc1120
Issue Description:
If a property and a method with the same name exist, then (at least in one circumstance) the compiler interprets a reference to the property as a reference to the method, or rather as a pointer to the method. I can reproduce this in a playground in Xcode 8 like this:
{{
protocol QueryRow {
var key: Any { get }
func key(at index: UInt) -> Any?
}
var row: QueryRow
row.key as? String
}}
This obviously produces an error that 'row' hasn't been initialized yet. But there's also a warning: "cast from '(UInt) -> Any?' to unrelated type 'String' always fails". This implies that the compiler treated `.key` as a reference to the method, not the property. I have not been able to figure out a syntax to use to work around this and get a reference to the property.
This is causing trouble in the real world, because this situation manifests in the (bridged) API of our Objective-C framework Couchbase Lite, when used from Swift 3 (but not earlier). We have a class CBLQueryRow that includes the following:
{{
@Property (readonly) id key;
}}
In Swift 3 this becomes
{{
open var key: Any { get }
open func key(at index: UInt) -> Any?
}}
which triggers this problem. Here's an actual warning message from the Swift 3 compiler in Xcode 8.0:
{{
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 our API, while the `key()` method that ends up hiding it it is obscure and little-used.
The text was updated successfully, but these errors were encountered: