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-4909] Closure with generic type (being void) requires explicitly ignoring #47486

Open
ffried opened this issue May 16, 2017 · 2 comments
Open

[SR-4909] Closure with generic type (being void) requires explicitly ignoring #47486

ffried opened this issue May 16, 2017 · 2 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself feature A feature request or implementation

Comments

@ffried
Copy link
Contributor

ffried commented May 16, 2017

Previous ID SR-4909
Radar None
Original Reporter @ffried
Type Bug

Attachment: Download

Environment

$ swift --version
Apple Swift version 4.0-dev (LLVM f175cad503, Clang 51f7aba0dc, Swift 79b6334)
Target: x86_64-apple-macosx10.9

Toolchain: 4.0-DEVELOPMENT-SNAPSHOT-2017-05-15-a

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

md5: 5f55ffb158612da88cda3b44161cc4d7

relates to:

  • SR-4908 Protocol default init implementation not working for generic type

Issue Description:

The following source code

struct BlockHandler<T> {
    init(block: @escaping (T) -> ()) {}
}

let handler = BlockHandler {}
let handler2 = BlockHandler<()> {}

gives the following output:

s4_genericVoidClosure.swift:11:28: error: contextual type for closure argument list expects 1 argument, which cannot be implicitly ignored
let handler = BlockHandler {}
                           ^
                            _ in 
s4_genericVoidClosure.swift:12:33: error: contextual type for closure argument list expects 1 argument, which cannot be implicitly ignored
let handler2 = BlockHandler<()> {}
                                ^
                                 _ in

because the closure (where T == ()) is actually (()) -> () instead of () -> ().
While this might even be intentional, there's no clean way of working around this without adding an extension which declares the closure as being a void closure:

extension BlockHandler where T == () {
    init(block: @escaping () -> ()) {}
}

However, this means I need to implement the initializer twice in the exact same way, because I can't call the default initializer from the extension (as this causes an ambiguity error):

s4_genericVoidClosure.swift:7:6: error: ambiguous use of 'init(block:)'
        self.init(block: block)
        ^
s4_genericVoidClosure.swift:2:5: note: found this candidate
    init(block: @escaping (T) -> ()) {}
    ^
s4_genericVoidClosure.swift:6:5: note: found this candidate
    init(block: @escaping () -> ()) {
    ^
@belkadan
Copy link
Contributor

This is indeed intentional, but it might be reasonable to allow the callback if the arguments are not explicitly written (that is, if there's no in).

@swift-ci
Copy link
Collaborator

Comment by Ilya Kulakov (JIRA)

I have hit this problem while trying to use XCTContext.runActivity that is declared as:

{code:swift}class func runActivity<Result>(named name: String, block: (XCTActivity) throws -> Result) rethrows -> Result

@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
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself feature A feature request or implementation
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@belkadan @ffried @swift-ci