Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-8944] Ambiguous use in constrained protocol extension #51449

Closed
macdrevx opened this issue Oct 8, 2018 · 2 comments
Closed

[SR-8944] Ambiguous use in constrained protocol extension #51449

macdrevx opened this issue Oct 8, 2018 · 2 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.

Comments

@macdrevx
Copy link

macdrevx commented Oct 8, 2018

Previous ID SR-8944
Radar None
Original Reporter @macdrevx
Type Bug
Status Resolved
Resolution Duplicate
Environment

Swift 4.2, Xcode 10

Additional Detail from JIRA
Votes 0
Component/s
Labels Bug
Assignee None
Priority Medium

md5: eb6e35622ac1836f179e1c63153da001

duplicates:

  • SR-7425 ambiguity error when class constraining protocol extension fulfills protocol requirement

Issue Description:

Possibly related to SR-7940

Consider the following:

protocol Foo: class {
    var foo: Int { get }
}

extension Foo where Self: Bar {
    func run() {
        _ = foo
    }
}

class Bar {
    var foo: Int = 0
}

This produces:
error: ambiguous use of 'foo'
_ = foo
^

Given the type constraint on the protocol, don't the 2 candidates have be the same? What's a situation where they'd differ? I tried adjusting the call site to

_ = (self as Foo).foo
_ = (self as Bar).foo

to compare results, but every time, it appears to call the same method. This is true whether foo is defined in a protocol extension or not, whether I'm calling run on a subclass of Bar or not.

@hamishknight
Copy link
Collaborator

Although I don't believe it's currently possible to conform a subclass of Bar to Foo in such a way where Bar's foo property (or an override of it) isn't used in order to satisfy the conformance, it could be possible if we ever exposed a way for the user to satisfy a protocol requirement with a differently named member.

That being said, I recently implemented a ranking rule where the member on the concrete type (Bar in this case) is preferred over the protocol requirement – therefore your code will be unambiguous and compile in Swift 5.

@macdrevx
Copy link
Author

macdrevx commented Oct 8, 2018

Very interesting. Thank you!

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.
Projects
None yet
Development

No branches or pull requests

2 participants