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-6030] Wildcard argument in closure doesn't match variadic arguments #48587

Open
swift-ci opened this issue Sep 29, 2017 · 6 comments
Open

[SR-6030] Wildcard argument in closure doesn't match variadic arguments #48587

swift-ci opened this issue Sep 29, 2017 · 6 comments
Assignees
@slavapestov
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-6030
Radar rdar://problem/29698921
Original Reporter helge (JIRA User)
Type Bug
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, TypeChecker
Assignee @slavapestov
Priority Medium

md5: d85de9867b74906b89b8ac52301fe1b6

Issue Description:

I have a typealias which goes like this:

public typealias Next = (Any...) -> Void

Which I use like this:

    let endNext : Next = { _ in
      response.writeHead(404)
      response.end()
    }

Works fine in Swift 1...2...3, but Swift 4 says:

Cannot convert value of type '(_) -> ()' to specified type 'Next' (aka '(Any...) -> ()')

So it looks like vararg signatures cannot be wild-carded. Which in turn sounds like a bug to me? :-)

Full code: https://github.com/NozeIO/Noze.io/blob/master/Sources/connect/Connect.swift#L87
@belkadan
Copy link
Contributor

Yeah, it does seem like this should work. @xedin, @rudkx?

@swift-ci
Copy link
Collaborator Author

Comment by Helge Heß (JIRA)

Also: https://www.google.de/search?q=SR-6030&rlz=1C5CHFA_enDE710DE710&source=lnms&tbm=isch&sa=X&ved=0ahUKEwiwuZW_4MrWAhWHvRQKHWjgBG8Q_AUICigB&biw=960&bih=960

@xedin
Copy link
Member

xedin commented Sep 29, 2017

That should work, and in fact it does work in `-swift-version 3` mode still, I think it has to do with SE-0110 and parens for the argument here because solver fails `($T0) -> Void conv (Any...) -> Void` constraint in `-swift-version 4` mode.

@rudkx
Copy link
Member

rudkx commented Sep 29, 2017

@swift-ci create

@rnapier
Copy link

rnapier commented Jun 11, 2020

This may be closely related to the fact that type-inference fails on these closures, and you need to provide the type explicitly:

func this(_ hello: (Int...) -> ()) {}

This cannot be called as:

this { foo in }

It requires:

this { (foo: Int...) in }

@swift-ci
Copy link
Collaborator Author

Comment by Helge Heß (JIRA)

Interesting, thanks!

Need to check what I'm currently doing there, close to 3 years after filing :-) Looks like I explicitly type it out as you suggest: https://github.com/Macro-swift/MacroExpress/blob/master/Sources/express/Route.swift#L255

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@slavapestov slavapestov

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
5 participants
@xedin @rudkx @rnapier @belkadan @swift-ci