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-8563] Ambiguous type deduction for input argument for closure using generic func #51081

Closed
swift-ci opened this issue Aug 17, 2018 · 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-8563
Radar rdar://problem/43437626
Original Reporter fantastik (JIRA User)
Type Bug
Status Closed
Resolution Done
Environment

XCode Version 9.4.1 (9F2000), MacOS Version 10.13.4,

Apple Swift version 4.1.2 (swiftlang-902.0.54 clang-902.0.39.2)

Additional Detail from JIRA
Votes 1
Component/s Compiler
Labels Bug, TypeChecker
Assignee fantastik (JIRA)
Priority Medium

md5: 4b4ec0b8160662bf76ebb89d9423172c

is duplicated by:

  • SR-12669 Ambiguity with arity in overloaded generic functions
  • SR-12754 generic overload distinguished by number of parameters of passed function

Issue Description:

Compiler could not deduct type for input args for generic closure (it resolves it as possible tuple and as possible separated args).

func foo<A,Z>(_ f: @escaping (A) -> Z) -> (A) -> Z {
    return f
}


func foo<A,B,Z>(_ f: @escaping (A, B) -> Z) -> (A, B) -> Z {
    return f
}


let a = foo { (a1: Int, a2: String) in }
a(1)

Result:

error: ambiguous use of 'foo'
let a = foo { (a1: Int, a2: String) in
        ^
note: found this candidate
func foo<A,Z>(_ f: @escaping (A) -> Z) -> (A) -> Z {
     ^
note: found this candidate
func foo<A,B,Z>(_ f: @escaping (A, B) -> Z) -> (A, B) -> Z {

That seems like closure should deduct are input is tuple or separated args.

@belkadan
Copy link
Contributor

Still happens on master. @xedin, @rudkx?

@xedin
Copy link
Member

xedin commented Aug 17, 2018

This looks like a tuple splat which we haven't fixed yet, because when `foo<A,Z>` is attempted it uses `(Int, String)` as its single parameter, but in case of `foo<A,B,Z>` it argument type gets unpacked into `Int` and `String`...

@xedin
Copy link
Member

xedin commented Aug 17, 2018

@swift-ci create

@rudkx
Copy link
Member

rudkx commented Aug 17, 2018

There is nothing wrong with the first function here matching.

We've never disambiguated in this case though.

To do so you need to decide for each of these which function is the best one to call:

foo { a, b in }
foo { (a, b) in }
foo { (a: Int, b: Int) in }

People currently write all three of these for both the two-argument case and the single (two-tuple) argument case.

One could argue that the first of these three is "obviously" a better match for the two-argument function, but it's not so obvious which of the last two should prefer.

IMO this at least needs discussion on the Swift Evolution forum, if not a full proposal.

@xedin
Copy link
Member

xedin commented Mar 19, 2020

fantastik (JIRA User) luciano (JIRA User) reports that this issue has been fixed by #30440 Please use next master snapshot to verify.

@swift-ci
Copy link
Collaborator Author

Comment by Dmitry Koryakin (JIRA)

@xedin it has been fixed. Checked on:

Swift version 5.3-dev (LLVM 0704986941, Swift e1b6eb6c23)

Target: x86_64-apple-darwin19.3.0

@xedin
Copy link
Member

xedin commented Mar 19, 2020

fantastik (JIRA User) Thank you for confirming! I'm going to close this issue.

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

4 participants