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-2324] Optional closure type is always considered @escaping #44931

Closed
swift-ci opened this issue Aug 11, 2016 · 6 comments
Closed

[SR-2324] Optional closure type is always considered @escaping #44931

swift-ci opened this issue Aug 11, 2016 · 6 comments
Assignees
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-2324
Radar rdar://problem/27795901
Original Reporter ilijatovilo (JIRA User)
Type Bug
Status Resolved
Resolution Done
Environment

OSX 10.11.6 (15G31)
MacBook Pro (Retina, Mid 2012)
Version 8.0 beta 5 (8S193k)
Toolchain: Swift Development Snapshot 2016-08-07 (a)

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug
Assignee @milseman
Priority Medium

md5: ab4ee203bb7d77d3976562cd10a4342c

is duplicated by:

Issue Description:

The following code snippet doesn't work anymore in the current Swift 3 snapshot:

func takes(anOptionalClosure: (() -> Void)?) {
    if let aClosure = anOptionalClosure {
        aClosure()
    }
}

func takes(aClosure: () -> Void) {
    takes(anOptionalClosure: aClosure)
}

> main.swift:18:30: Cannot convert value of type '() -> Void' to expected argument type '(() -> Void)?'

My guess is that the type checker thinks that `(() -> Void)?` is interpreted as a tuple type. But the parens are only necessary to make the closure optional. Interestingly this only happens with function types. `(String)?` e.g. type checks correctly.

The following snippet works as expected:

func takes(anOptionalClosure: (() -> Void)?) {
    if let aClosure = anOptionalClosure {
        aClosure()
    }
}

// Hint: Added two surrounding parens to the argument type
func takes(aClosure: (() -> Void)) {
    takes(anOptionalClosure: aClosure)
}
@belkadan
Copy link
Contributor

The actual issue here is that optional closures are implicitly @escaping right now.

@belkadan
Copy link
Contributor

@milseman, do we have a JIRA or Radar for this already?

@milseman
Copy link
Mannequin

milseman mannequin commented Aug 12, 2016

Yes, <rdar://problem/27795901>

@swift-ci
Copy link
Collaborator Author

swift-ci commented Sep 7, 2016

Comment by Shawn Erickson (JIRA)

Note I added a comment to SR-2444 which is marked resolved because I assume it is considered a duplicate of this issue. What is described in SR-2444 is problematic still in Xcode 8 GM.

https://bugs.swift.org/browse/SR-2444?focusedCommentId=17861&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17861

@milseman
Copy link
Mannequin

milseman mannequin commented Sep 19, 2016

Also, rdar://problem/28372774

@milseman
Copy link
Mannequin

milseman mannequin commented Sep 23, 2016

With #4905 produces the correct error message here:

...: error: unexpected note produced: parameter 'aClosure' is implicitly non-escaping
func takes(aClosure: () -> Void) {
           ^
...: error: unexpected error produced: passing non-escaping parameter 'aClosure' to function expecting an @escaping closure
    takes(anOptionalClosure: aClosure)
                             ^

@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

2 participants