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-13020] Concrete associated type leaks through opaque type #55465

Closed
typesanitizer opened this issue Jun 15, 2020 · 2 comments
Closed

[SR-13020] Concrete associated type leaks through opaque type #55465

typesanitizer opened this issue Jun 15, 2020 · 2 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself not a bug Resolution → not a bug: Reported as a bug but turned out to be expected behavior or programmer error opaque types Feature → types: opaque types

Comments

@typesanitizer
Copy link

Previous ID SR-13020
Radar rdar://problem/64405639
Original Reporter @typesanitizer
Type Bug
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug
Assignee None
Priority Medium

md5: 0f390e9405cf0f9b08177e5e6fe29492

Issue Description:

Consider the following code:

protocol Container {
    associatedtype Item: Equatable
    var count: Int { get }
    subscript(i: Int) -> Item { get }
}
extension Array: Container where Element: Equatable { }
func f<T: Equatable>(_ items: [T]) -> some Container {
    return items
}
let x = f([0])
let y = f([1])
let z = x[0] == y[0]

I don't think this should compile, but it does! `x` and `y` are different containers, how/why is the compiler able to tell that the different calls to `f` are returning opaque types with the same associated type? I think the only information that should be accessible is that the element is Equatable. This means that `x[0] == x[1]` would compile but `x[0] == y[0]` would not. It seems like information about the concrete type is "leaking through" and being used to check the call to `==`.

@typesanitizer
Copy link
Author

@swift-ci create

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@slavapestov
Copy link
Member

x and y are different containers, but they have the same type because the opaque return type is known to always have the same underlying type. So even though the compiler doesn't know the types of x[0] and y[0], it knows they're the same.

@AnthonyLatsis AnthonyLatsis added not a bug Resolution → not a bug: Reported as a bug but turned out to be expected behavior or programmer error opaque types Feature → types: opaque types and removed bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. labels Nov 4, 2022
@AnthonyLatsis AnthonyLatsis added the bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. label Nov 14, 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 not a bug Resolution → not a bug: Reported as a bug but turned out to be expected behavior or programmer error opaque types Feature → types: opaque types
Projects
None yet
Development

No branches or pull requests

3 participants