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.

Sign up for GitHub

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

Jump to bottom

[SR-1616] Resolve name conflicts for associatedtype names #44225

Open
swift-ci opened this issue May 25, 2016 · 5 comments
Open

[SR-1616] Resolve name conflicts for associatedtype names #44225

swift-ci opened this issue May 25, 2016 · 5 comments
Labels
compiler The Swift compiler in itself feature A feature request or implementation improvement

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-1616
Radar None
Original Reporter Andreas Grosam (JIRA User)
Type Improvement
Additional Detail from JIRA
Votes 12
Component/s Compiler
Labels Improvement, LanguageFeatureRequest
Assignee None
Priority Medium

md5: 85eaf1679db0a25d3d656686bf1b62fe

Issue Description:

This does currently not compile:

Having two protocols with the same name for associatedtype declaration:

protocol P1 {    
    associatedtype ValueType
    func foo(param: ValueType)    
}
protocol P2 {
    associatedtype ValueType
    func bar(param: ValueType)    
}

A class or struct conforming to this two protocols:

struct S: P1, P2 {
    func foo(param: Int) {}
    func bar(param: String) {}
}

Expected:
The compiler should be able to resolve the types.

Actual:
The compiler issues nonsensical errors.

Further improvements:

In order to resolve naming conflicts, a developer should be able to use qualified names. For example:

struct S2<T1, T2>: P1, P2 {
    typealias P1.ValueType = T1
    typealias P2.ValueType = T2
    func foo(param: T1) {}
    func bar(param: T2) {}
}

The code above does not compile.

Compiler:
Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.31)
@swift-ci
Copy link
Collaborator Author

Comment by Franklin Yu (JIRA)

I asked this problem on StackOverflow and got some workaround there. It is still a missing feature of the compiler through.

@swift-ci
Copy link
Collaborator Author

Comment by Andreas Grosam (JIRA)

I do not consider the proposed solution in SO as a workaround, since it doesn't solve the problem. This problem stems from the fact, that Swift doesn't let us use qualified names. But many problems arise due to those name conflicts and could be solved easily using qualified names. Of course, Swift would need to refer to names with their fully qualified names internally, across its implementation.

@swift-ci
Copy link
Collaborator Author

Comment by Franklin Yu (JIRA)

I do not consider the proposed solution in SO as a workaround, since it doesn't solve the problem.

Andreas Grosam (JIRA User) A workaround does not solve the problem; it works around the problem. Sorry if I confused you.

@swift-ci
Copy link
Collaborator Author

Comment by Benjamin GARRIGUES (JIRA)

Note that some very used libraries tend to not have paid attention to this problem.
Eg: RxSwift where the two core protocols ObserverType and ObservableType both use "E" (like Event) as an associate type.
Meaning you can't observe one type and emit another.

Seeing that that the general trend is to use single letter names for associated types, this looks like a critical limitation to me.

@swift-ci
Copy link
Collaborator Author

Comment by Dale Buckley (JIRA)

Is there any update on this issue? We have hit this a few times the larger our project gets.

@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
Assignees
No one assigned
Labels
compiler The Swift compiler in itself feature A feature request or implementation improvement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@swift-ci