[SR-2444] @escaping failing on optional blocks

[gonzalolarralde]

Previous ID	SR-2444
Radar	None
Original Reporter	@gonzalolarralde
Type	Bug
Status	Resolved
Resolution	Done

Environment

Ubuntu 16.04
swift-master @ HEAD:a23bb43d7141599786e45a75876c995611073e45

Additional Detail from JIRA

Votes	1
Component/s	Compiler
Labels	Bug
Assignee	@milseman
Priority	Medium

md5: e30e726be4270da7c451adbc31564015

duplicates:

• SR-2324 Optional closure type is always considered @escaping

Issue Description:

@escaping doesn't seem to be working on Optional block parameters.

This is related to SR-2166, but in that case being the default @escaping a safer option than @NoEscape the workaround was to let it @escaping.

swift-corelibs-libdispatch/src/swift/Private.swift:72:116: error: @escaping may only be applied to parameters of function type
public func dispatch_data_create(_ buffer: UnsafeRawPointer, _ size: Int, _ queue: DispatchQueue?, _ destructor: (@escaping () -> Void)?) -> dispatch_data_t
                                                                                                                  ~^~~~~~~~~

swift-corelibs-libdispatch/src/swift/Wrapper.swift:216:83: error: @escaping may only be applied to parameters of function type
        func setCancelHandler(qos: DispatchQoS, flags: DispatchWorkItemFlags, handler: (@escaping DispatchSourceHandler)?)
                                                                                        ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Expected result:

@escaping optional blocks should compile.

[swift-ci]

Comment by Shawn Erickson (JIRA)

I am hitting this issue in the Swift variant in Xcode 8 GM...

typealias MyCallback = (String)->()

// Happy
func foo1(bar: String, completion: ((String)->())) {
    completion(bar)
}

// Happy
func foo2(bar: String, completion: MyCallback) {
    completion(bar)
}

// Happy
func foo3(bar: String, completion: ((String)->())? = nil) {
    completion?(bar)
}

// Happy
func foo4(bar: String, completion: MyCallback? = nil) {
    completion?(bar)
}

// Happy
func foo5(bar: String, completion: Optional<MyCallback> = nil) {
    completion?(bar)
}

// Happy
func foo6(bar: String, completion: @escaping (String)->()) {
    completion(bar)
}

// Happy
func foo7(bar: String, completion: @escaping MyCallback) {
    completion(bar)
}

// Unhappy...
// "@escaping attribute only applies to function types"
func foo8(bar: String, completion: @escaping ((String)->())? = nil) {
    completion?(bar)
}

// Unhappy...
// "@escaping attribute only applies to function types"
func foo9(bar: String, completion: @escaping MyCallback? = nil) {
    completion?(bar)
}

// Unhappy...
// "@escaping attribute only applies to function types"
func foo10(bar: String, completion: (@escaping ((String)->()))? = nil) {
    completion?(bar)
}

// Unhappy...
// "@escaping attribute only applies to function types"
func foo11(bar: String, completion: (@escaping MyCallback)? = nil) {
    completion?(bar)
}

// Unhappy...
// "@escaping attribute only applies to function types"
func foo12(bar: String, completion: Optional<@escaping MyCallback> = nil) {
    completion?(bar)
}

[swift-ci]

Comment by Kevin Chen (JIRA)

I have the same issue as jaegerpicker (JIRA User)

Now, I just removed the @escaping keyword to make the project compiling again, but I don't think it's the correct way to do it

[swift-ci]

Comment by John Grange (JIRA)

This is definitely no the solution, as in my case the code requires the block to be marked as escaping. Any other thoughts?

[milseman]

Kevin, that is the correct way to fix it, as it's already escaping.
John, could you elaborate?

[gonzalolarralde]

@milseman so optional blocks are `@escaping` by default? If that's correct I don't understand what's the point on doing that. Could you please explain?

Thanks.

[milseman]

That is unfortunately the case for Swift 3. Here are the semantics for escaping in Swift 3:

1) Closures in function parameter position are non-escaping by default
2) All other closures are escaping

Thus, all generic type argument closures, such as Array and Optional, are escaping.

This puts us in the very unfortunate situation where

((Int)->Int)?

is escaping, even as a parameter type, as that is sugar for

Optional<(Int)->Int>

Optional is hurt the most by this, and the proposal does not special case the '?' syntax, though any other generic type is as well (and similarly tuples).

I would like to remedy this in post-Swift-3. Relevant emails:
https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160905/003185.html
https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160905/003200.html

[BigZaphod]

I'm hitting this too. If I remove @escaping for my optional functions, then the compiler crashes with a segmentation fault 11 for my project

Edit: Looks like the crashing is something else, but still super frustrating obviously since ALL of this project worked in the beta just prior to GM. Grr.

[milseman]

That might not be related. @escaping on optional closure didn't "work" in the prior beta, it was just silently dropping it on the floor as it's always been escaping. That is, this is a diagnostic change, but not a semantic change WRT optional closures.

Could you either attach your crash log here, or else spawn a different JIRA for the crash?

[BigZaphod]

I've opened a new issue and attached a project file, too: [SR-2603]

[milseman]

With #4905 we no longer print the "@escaping" on the generated interface, leading to the confusing scenario where the developer thinks they need to write it themselves. These optional closures are already escaping.