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-5260] Extensions on Typealiased Existential Protocols #47835

Closed
swift-ci opened this issue Jun 19, 2017 · 6 comments
Closed

[SR-5260] Extensions on Typealiased Existential Protocols #47835

swift-ci opened this issue Jun 19, 2017 · 6 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-5260
Radar None
Original Reporter altece (JIRA User)
Type Bug
Status Closed
Resolution Invalid
Environment

Swift 4
Xcode 9.0 beta (9M136h)

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

md5: 5961a05fab1e2142b9a0b4821da3e20a

Issue Description:

Since extension A where Self: B is valid, and C is defined as any A that also inherits from B, extension C should be just as valid.

    protocol A {}
    protocol B {}
    typealias C = A & B // valid

    struct Foo: C {} // valid

    extension A where Self: B {} // valid
    extension C {} // Error: Non-nominal type 'C' (aka 'A & B') cannot be extended }}
@belkadan
Copy link
Contributor

cc @slavapestov, @DougGregor

@slavapestov
Copy link
Member

The thing is that 'extension A where Self : B' is not the same as 'extension B where Self : A', especially if one of A or B is a class type. But we could support this eventually once we work out the quirks.

@swift-ci
Copy link
Collaborator Author

Comment by Steven Brunwasser (JIRA)

How so would they result in different definitions? What kind of pitfalls should I watch out for if I were to make this assumption?

@DougGregor
Copy link
Member

Swift 4's access control model would treat them differently. "extension A where Self: B" would have access to private members of A (but not B), whereas "extension B where Self: A" would have access to private members of B (but not A).

@DougGregor
Copy link
Member

The compiler is correct to reject these extensions. Changing the language to accept such extensions is something that would need to go through the Swift evolution process.

@swift-ci
Copy link
Collaborator Author

Comment by Steven Brunwasser (JIRA)

Ah, ok. That makes sense. Thanks for the clarification!

@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. compiler The Swift compiler in itself
Projects
None yet
Development

No branches or pull requests

4 participants