Skip to content

RecoverableError's resultHandler needs @escaping #1539

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
Merged
merged 1 commit into from
May 24, 2019
Merged

RecoverableError's resultHandler needs @escaping #1539

merged 1 commit into from
May 24, 2019

Conversation

itaiferber
Copy link
Contributor

What's in this pull request?
Resolves SR-4405/rdar://problem/36911792 by adding @escaping to resultHandler.

[This mirrors swiftlang/swift#16182]

@itaiferber itaiferber requested a review from parkera April 26, 2018 18:12
@itaiferber
Copy link
Contributor Author

@swift-ci Please test

@itaiferber
Copy link
Contributor Author

@swift-ci Please test

1 similar comment
@itaiferber
Copy link
Contributor Author

@swift-ci Please test

@millenomi
Copy link
Contributor

@itaiferber: @escaping is implied for optional closures, since they need to be stored in the Optional<_>.

millenomi
millenomi suggested changes May 30, 2018
View reviewed changes
Foundation/NSError.swift Outdated
@@ -147,7 +147,7 @@ open class NSError : NSObject, NSCopying, NSSecureCoding, NSCoding {
internal typealias UserInfoProvider = (_ error: Error, _ key: String) -> Any?
internal static var userInfoProviders = [String: UserInfoProvider]()

open class func setUserInfoValueProvider(forDomain errorDomain: String, provider: (/* @escaping */ (Error, String) -> Any?)?) {
open class func setUserInfoValueProvider(forDomain errorDomain: String, provider: (@escaping (Error, String) -> Any?)?) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This must drop the @escaping before it can build. Optional where X is a closure type is always implicitly escaping.

@itaiferber itaiferber force-pushed the recoverableerror-escaping-resulthandler branch from d9dc66f to 098997a Compare May 30, 2018 00:49
@itaiferber
Copy link
Contributor Author

@millenomi Thanks — hadn't had the time to fix this up. I dropped that commit, though I wonder if changing /* @escaping */ to /* implicitly @escaping */ would make it clearer that this isn't something that we couldn't add before (which we've had in the past), but rather, this is something that happens to be true

What do you think?

@millenomi
Copy link
Contributor

We have that pattern nowhere, and I'm not sure it adds anything.

@itaiferber
Copy link
Contributor Author

@swift-ci Please test

1 similar comment
@ikesyo
Copy link
Member

ikesyo commented May 24, 2019

@swift-ci Please test

@itaiferber itaiferber merged commit 9858f1b into swiftlang:master May 24, 2019
@itaiferber itaiferber deleted the recoverableerror-escaping-resulthandler branch May 24, 2019 20:01
@itaiferber
Copy link
Contributor Author

@ikesyo Thanks! Completely forgot about this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@millenomi millenomi millenomi requested changes

@parkera parkera parkera approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@itaiferber @millenomi @ikesyo @parkera