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

Thanks for your reply,
Sebastian


> On 10 Oct 2016, at 19:10, Joe Groff <[email protected]> wrote:
> 
> 
>> On Oct 10, 2016, at 8:20 AM, Sebastian Hagedorn via swift-users 
>> <[email protected]> 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.
> 
> -Joe

_______________________________________________
swift-users mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-users

Reply via email to