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-2444] @escaping failing on optional blocks #45049

Closed
gonzalolarralde opened this issue Aug 21, 2016 · 10 comments
Closed

[SR-2444] @escaping failing on optional blocks #45049

gonzalolarralde opened this issue Aug 21, 2016 · 10 comments
Assignees
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@gonzalolarralde
Copy link
Contributor

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:

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
Copy link
Collaborator

swift-ci commented Sep 7, 2016

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
Copy link
Collaborator

swift-ci commented Sep 8, 2016

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
Copy link
Collaborator

swift-ci commented Sep 8, 2016

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
Copy link
Mannequin

milseman mannequin commented Sep 8, 2016

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

@gonzalolarralde
Copy link
Contributor Author

@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
Copy link
Mannequin

milseman mannequin commented Sep 9, 2016

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
Copy link

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![]( This is quite upsetting because @escaping on optional functions worked in a prior Xcode beta but not in the GM)

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
Copy link
Mannequin

milseman mannequin commented Sep 9, 2016

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
Copy link

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

@milseman
Copy link
Mannequin

milseman mannequin commented Sep 23, 2016

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.

@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
Projects
None yet
Development

No branches or pull requests

3 participants