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-11540] Swift compiler behavior change for functions with generic return types used as parameters #53941

Closed
swift-ci opened this issue Sep 27, 2019 · 7 comments
Closed

[SR-11540] Swift compiler behavior change for functions with generic return types used as parameters #53941

swift-ci opened this issue Sep 27, 2019 · 7 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-11540
Radar rdar://problem/56054446
Original Reporter loyalt (JIRA User)
Type Bug
Status Resolved
Resolution Done
Environment

MacOS Mojave 10.14.6

Xcode 11.0

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

Target: x86_64-apple-darwin18.7.0

(Choosing swift language version 4.0, 4.2, 5.0 in Xcode all exhibits this behavior)

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

md5: d5f20af32525b4b56957d3c29173ad1e

Issue Description:

When using generics in a function that takes functions as parameters, the following is accepted, and correctly chooses the first function:

func f(action: () -> Void) -> Void {
}

func f<T>(action: (T) -> Void) -> Void {
}

f(action: { return })

whereas the following was previously accepted, but is now a compiler error indicating ambiguous use of `f(action🙂`:

func f<R>(action: () -> R) -> Void {
}

func f<T, R>(action: (T) -> R) -> Void {
}

f(action: { return })
@theblixguy
Copy link
Collaborator

In tryOptimizeGenericDisjunction(), we call compareDeclarations() which is ranking the above overloads as "unordered" (meaning they're not better or worse than each other), which is why we're treating it as ambiguous. I thought it would pick f<R> as more "specialised" than f<T, R>, but apparently not.

cc @xedin

@belkadan
Copy link
Contributor

What do you mean by "previously accepted"? This seems to be rejected all the way back to Swift 4.2 for me.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Oct 1, 2019

Comment by Loyal Tingley (JIRA)

Sorry, I was mistaken about my repro case. I have re-checked using the swift:4.2 Docker image. The type ((T)) -> R worked on 4.2, (T) -> R is a compiler error.

@xedin
Copy link
Member

xedin commented Oct 7, 2019

It looks to me like a bug in SE-0110 enforcement because only first overload of `f` should match call like "f { return }", second overload, which has a parameter, should only match if the parameter explicitly used in the body of the closure.

@xedin
Copy link
Member

xedin commented Oct 7, 2019

@swift-ci create

@LucianoPAlmeida
Copy link
Collaborator

The issue has been fixed on master, loyalt (JIRA User) could you please verify using the lastest snapshot and close? Thanks

@AnthonyLatsis
Copy link
Collaborator

#30440

@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
No one assigned
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
6 participants
@xedin @belkadan @theblixguy @LucianoPAlmeida @swift-ci @AnthonyLatsis