We encountered a very surprising behaviour in one of our apps, and believe it’s a bug/missing warning in the Swift compilter, but it would be great if someone could confirm we’re not missing a piece before I file a bug report.
This snippet reproduces the issue:
protocol MyProto {
var title: String? { get }
}
let tuple = (x: 100, y: 100)
// Results in a warning as expected: Cast always fails
let castedTupleToInt = tuple as? Int
// No warning, although cast will always fail
let castedTuple = tuple as? MyProto
The way I see it, it should be pretty easy for the compiler to detect that casting a tuple to a protocol always fails, since there’s no way for a tuple to conform to a protocol.
We came across the bug when we refactored a method to return a tuple instead of a protocol type, and thought the compiler would make us aware of all the call sites that need to adopt the the refactored return type. However, wherever we casted the return type, no warning was raised and the code just silently returned early because the cast always fails at runtime (as it should, of course).
In general, we can't say that a cast to protocol type always fails, since some other module in your program could extend the type to conform to the protocol. Although tuples aren't allowed to conform to protocols today, that's not a fundamental limitation we intend to live with forever.
-Joe
···
On Oct 10, 2016, at 8:20 AM, Sebastian Hagedorn via swift-users <swift-users@swift.org> wrote:
We encountered a very surprising behaviour in one of our apps, and believe it’s a bug/missing warning in the Swift compilter, but it would be great if someone could confirm we’re not missing a piece before I file a bug report.
This snippet reproduces the issue:
protocol MyProto {
var title: String? { get }
}
let tuple = (x: 100, y: 100)
// Results in a warning as expected: Cast always fails
let castedTupleToInt = tuple as? Int
// No warning, although cast will always fail
let castedTuple = tuple as? MyProto
The way I see it, it should be pretty easy for the compiler to detect that casting a tuple to a protocol always fails, since there’s no way for a tuple to conform to a protocol.
We came across the bug when we refactored a method to return a tuple instead of a protocol type, and thought the compiler would make us aware of all the call sites that need to adopt the the refactored return type. However, wherever we casted the return type, no warning was raised and the code just silently returned early because the cast always fails at runtime (as it should, of course).
Since it is currently *not* possible for tuples to conform to protocols, isn’t it worth a warning (if my assumption that this would be easy to implement is correct), even if it may be obsolete in the future?
Thanks for your reply,
Sebastian
···
On 10 Oct 2016, at 19:10, Joe Groff <jgroff@apple.com> wrote:
On Oct 10, 2016, at 8:20 AM, Sebastian Hagedorn via swift-users <swift-users@swift.org> wrote:
We encountered a very surprising behaviour in one of our apps, and believe it’s a bug/missing warning in the Swift compilter, but it would be great if someone could confirm we’re not missing a piece before I file a bug report.
This snippet reproduces the issue:
protocol MyProto {
var title: String? { get }
}
let tuple = (x: 100, y: 100)
// Results in a warning as expected: Cast always fails
let castedTupleToInt = tuple as? Int
// No warning, although cast will always fail
let castedTuple = tuple as? MyProto
The way I see it, it should be pretty easy for the compiler to detect that casting a tuple to a protocol always fails, since there’s no way for a tuple to conform to a protocol.
We came across the bug when we refactored a method to return a tuple instead of a protocol type, and thought the compiler would make us aware of all the call sites that need to adopt the the refactored return type. However, wherever we casted the return type, no warning was raised and the code just silently returned early because the cast always fails at runtime (as it should, of course).
In general, we can't say that a cast to protocol type always fails, since some other module in your program could extend the type to conform to the protocol. Although tuples aren't allowed to conform to protocols today, that's not a fundamental limitation we intend to live with forever.
Yeah, even for non-tuples it may be worthwhile to offer a warning that there isn't a currently-visible protocol conformance for the type of the operand when it's a concrete type. You could easily enough silence the warning by writing 'as Any as? P' or something like that if you really want to.
-Joe
···
On Oct 10, 2016, at 10:53 AM, Sebastian Hagedorn <sebastian@iosphere.de> wrote:
“Forever” is pretty long-term ;)
Since it is currently *not* possible for tuples to conform to protocols, isn’t it worth a warning (if my assumption that this would be easy to implement is correct), even if it may be obsolete in the future?
On 10 Oct 2016, at 19:57, Joe Groff <jgroff@apple.com> wrote:
On Oct 10, 2016, at 10:53 AM, Sebastian Hagedorn <sebastian@iosphere.de> wrote:
“Forever” is pretty long-term ;)
Since it is currently *not* possible for tuples to conform to protocols, isn’t it worth a warning (if my assumption that this would be easy to implement is correct), even if it may be obsolete in the future?
Yeah, even for non-tuples it may be worthwhile to offer a warning that there isn't a currently-visible protocol conformance for the type of the operand when it's a concrete type. You could easily enough silence the warning by writing 'as Any as? P' or something like that if you really want to.