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

Jump to bottom

[SR-11726] Type inferences work strangely for type parameters with self-conformance #54135

Closed
swift-ci opened this issue Nov 7, 2019 · 4 comments
Closed

[SR-11726] Type inferences work strangely for type parameters with self-conformance #54135

swift-ci opened this issue Nov 7, 2019 · 4 comments
Assignees
@CodaFi
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

swift-ci commented Nov 7, 2019

Previous ID SR-11726
Radar rdar://problem/56992973
Original Reporter koher (JIRA User)
Type Bug
Status Resolved
Resolution Won't Do
Environment

Apple Swift version 5.1 (swiftlang-1100.0.270.13 clang-1100.0.33.7)

Target: x86_64-apple-darwin18.7.0

Additional Detail from JIRA
Votes 1
Component/s Compiler
Labels Bug, TypeChecker
Assignee @CodaFi
Priority Medium

md5: 7c67e0a5cecbbb90e1467b347d7c63ae

Issue Description:

Although I am not sure if it is a bug, type inferences in the following code work strangely.

struct AError: Error {}
struct BError: Error {}

func foo<E: Error>(_ errors: [E]) {}

foo([AError(), BError()])
main.swift:6:5: error: in argument type '[Any]', 'Any' does not conform to expected type 'Error'
foo([AError(), BError()])
    ^

It may be better to be inferred as `[Error]`. I wonder if it is caused by omitting modifications of type inferences for type parameters with self-conformance when self-conformance of the `Error` protocol was introduced in [SE-0235|https://github.com/apple/swift-evolution/blob/master/proposals/0235-add-result.md].
@beccadax
Copy link
Contributor

beccadax commented Nov 7, 2019

@swift-ci create

@theblixguy
Copy link
Collaborator

The workaround is to explicitly specify the type eg. foo([AError(), BError()] as [Error]), but that ought to be inferred automatically.

@CodaFi
Copy link
Member

CodaFi commented Nov 21, 2019

The join of disparate bounds on the same type variable is never an existential without a contextual type in our system. It would be undesirable for this to be the case because in general as `Any` sits at the top of the lattice, and we'd start inferring that in a lot of cases instead of rightly rejecting code that shouldn't typecheck.

The right workaround is the one Suyash suggests.

@CodaFi
Copy link
Member

CodaFi commented Nov 21, 2019

This behaves as intended. If you need the bound to resolve to an existential type, you can use an explicit contextual type.

@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
Assignees

@CodaFi CodaFi

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
Milestone
No milestone
Development

No branches or pull requests
4 participants
@beccadax @theblixguy @CodaFi @swift-ci