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-12669] Ambiguity with arity in overloaded generic functions #55113

Closed
swift-ci opened this issue Apr 24, 2020 · 4 comments
Closed

[SR-12669] Ambiguity with arity in overloaded generic functions #55113

swift-ci opened this issue Apr 24, 2020 · 4 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-12669
Radar None
Original Reporter iankeen (JIRA User)
Type Bug
Status Resolved
Resolution Duplicate
Environment

Apple Swift version 5.2.2 (swiftlang-1103.0.32.6 clang-1103.0.32.51)
Target: x86_64-apple-darwin19.4.0

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

md5: 54264573fb7502c9478a950c75e2e178

duplicates:

  • SR-8563 Ambiguous type deduction for input argument for closure using generic func

Issue Description:

I am getting `Ambiguous use` errors on generic arities > 1, for example:

func foo<A>(_ closure: (A) -> Void) { }
func foo<A, B>(_ closure: (A, B) -> Void) { }
func foo<A, B, C>(_ closure: (A, B, C) -> Void) { }

foo { (a: Int) in }
foo { (a: Int, b: Int) in } // Ambiguous use of 'foo'
foo { (a: Int, b: Int, c: Int) in } // Ambiguous use of 'foo'

A workaround for this is to 'tupl-ify' the function parameters with arities >1 like so:

func foo<A>(_ closure: (A) -> Void) { }
func foo<A, B>(_ closure: ((A, B)) -> Void) { } // params wrapped in ()
func foo<A, B, C>(_ closure: ((A, B, C)) -> Void) { } // params wrapped in ()

foo { (a: Int) in }
foo { (a: Int, b: Int) in } // ok
foo { (a: Int, b: Int, c: Int) in } // ok

However without generics the original format works fine (no tupl-ifying required):

func foo(_ closure: (Int) -> Void) { }
func foo(_ closure: (Int, Int) -> Void) { }
func foo(_ closure: (Int, Int, Int) -> Void) { }

foo { (a: Int) in }
foo { (a: Int, b: Int) in }
foo { (a: Int, b: Int, c: Int) in }
@LucianoPAlmeida
Copy link
Collaborator

I just tested on a near master build that I have, this seems fixed
I think it is the same case of SR-8563

iankeen (JIRA User) can you please verify on the lastest master snapshot?

cc @xedin

@xedin
Copy link
Member

xedin commented Apr 24, 2020

@LucianoPAlmeida If you have tested it and it appears to be fixed I'd suggest you to either resolve or dupe it, that could always be reverted 🙂

@LucianoPAlmeida
Copy link
Collaborator

Sure @xedin, I just confirm using the snapshot toolchain, seems fixed I'll dupe this 🙂

@swift-ci
Copy link
Collaborator Author

Comment by Ian Keen (JIRA)

thanks ya'll!

@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.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@xedin @LucianoPAlmeida @swift-ci