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-14666] A protocol that declares conformance to a protocol with a constrained associatedtype must re-declare that associatedtype in order for implementers to compile #57017

Open
swift-ci opened this issue May 27, 2021 · 2 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself type checker Area → compiler: Semantic analysis

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-14666
Radar rdar://problem/78594698
Original Reporter reid.callan22 (JIRA User)
Type Bug
Environment

This is an issue both in a playground, in a project, and when compiling via the command line via swiftc.

Xcode 12.5 (12E262)

Swift 5.4

2020 M1 MacBook Air

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

md5: 2167a25b1b07254732a8dc9e526ba999

Issue Description:

The code block below displays the issue. The protocol A declares a constrained associatedtype. In order for Implementer to compile, that same associatedtype must be re-declared in protocol B, which declares conformance to protocol A. Re-declaring the associatedtype provokes a warning, and performing the warning's fix-it results in a build failure in Implementer, as well as a new, different warning on the declaration of B.

protocol PossibleResultType {}

protocol A {
    associatedtype ResultType: PossibleResultType
}

protocol B: A {
    // This code sample fails to compile. Uncommenting the redundant associatedtype declaration below causes compilation to succeed.
    // A warning occurs on this associatedtype declaration, for good reason. But, performing the warning's fit-it results in a build failure in Implementer and an additional warning in the declaration of B. This declaration should not be necessary, as ResultType is declared in A.
    //associatedtype ResultType: PossibleResultType
    func anotherResult() -> ResultType
}

extension String: PossibleResultType {}
struct Implementer: B {
    func anotherResult() -> String { return "foo" }
}
@swift-ci
Copy link
Collaborator Author

Comment by Reid Callan (JIRA)

If you update Implementer to make anotherResult() have an opaque return type (e.g. some View) then the redundant associatedtype is the only way to make this compile. The simple problem above can be solved by adding a typealias statement for ResultType within Implementer, but that becomes much less user friendly to do if an implementer makes use of an opaque return type.

The simple typealias is also not a great solution if you're modifying an existing protocol that has many implementers- requiring manual typealias statements to be placed in each one could be a potential huge pain.

@typesanitizer
Copy link

@swift-ci create

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
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 type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

2 participants