Version 7.3 (7D175), default Swift toolchain (Swift 2.2).
Additional Detail from JIRA
Votes
0
Component/s
Compiler
Labels
Bug
Assignee
None
Priority
Medium
md5: 0098b0c022008b618a21975f5c6952d4
Issue Description:
Take a protocol, with a protocol extension providing a default implementation of function A, which in turn calls function B. Function B has two default implmentations: one in an extension of the protocol which is constrained to a particular type, another in an unconstrained extension.
When calling function B directly on an instance of the type which matches the constrained extension's constraint, the correct implementation is used. That is, the implementation in the constrained extension.
However, when function A is called, it's call to function B always uses the implementation in the unconstrained extension.
This seems counter to the following in the Swift book:
If a conforming type satisfies the requirements for multiple constrained extensions that provide implementations for the same method or property, Swift will use the implementation corresponding to the most specialized constraints.
The following code demonstrates this (can be run in a playground):
Environment
Version 7.3 (7D175), default Swift toolchain (Swift 2.2).
Additional Detail from JIRA
md5: 0098b0c022008b618a21975f5c6952d4
Issue Description:
Take a protocol, with a protocol extension providing a default implementation of function A, which in turn calls function B. Function B has two default implmentations: one in an extension of the protocol which is constrained to a particular type, another in an unconstrained extension.
When calling function B directly on an instance of the type which matches the constrained extension's constraint, the correct implementation is used. That is, the implementation in the constrained extension.
However, when function A is called, it's call to function B always uses the implementation in the unconstrained extension.
This seems counter to the following in the Swift book:
The following code demonstrates this (can be run in a playground):
If
foo()
is declared in the protocol itself, this problem does not occur:The text was updated successfully, but these errors were encountered: