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-2316] typealias for block type not defaulting to @noescape #44923

Closed
swift-ci opened this issue Aug 10, 2016 · 5 comments
Closed

[SR-2316] typealias for block type not defaulting to @noescape #44923

swift-ci opened this issue Aug 10, 2016 · 5 comments
Assignees

Comments

@swift-ci
Copy link
Collaborator

@swift-ci swift-ci commented Aug 10, 2016

Previous ID SR-2316
Radar None
Original Reporter dgrove-oss (JIRA User)
Type Bug
Status Closed
Resolution Duplicate

Attachment: Download

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

md5: baffa86c07d4e4507700b040d298e309

duplicates:

  • SR-2053 [Regression] Using @NoEscape for a type aliased closure results in a compile error

is duplicated by:

  • SR-2355 Typealias and escaping
  • SR-2493 Escaping and Type-aliases don't work together
  • SR-2522 Function attribute @escaping does not apply to function type aliases

Issue Description:

Test case attached. When cleaning up the Dispatch overlay for Linux I observed that a typealias for a closure type did not pick up the default @NoEscape annotation. As a result, the attached test case does not compile (but should).

dgrove@dgrove-vb-swift:~/swift/tests$ swiftc NoEscape.swift 
NoEscape.swift:7:4: error: closure use of non-escaping parameter 'block' may allow it to escape
          block(y)
          ^
NoEscape.swift:4:10: note: parameter 'block' is implicitly non-escaping
func foo(block:(Int)->Void) {
         ^
               @escaping 
@belkadan
Copy link
Contributor

@belkadan belkadan commented Aug 10, 2016

cc @milseman. The actual behavior we want here is that @escaping is a property of the parameter, not the function type, but we don't currently allow you to write @escaping on typealiases. I think there's another JIRA or Radar for that.

@slavapestov
Copy link
Member

@slavapestov slavapestov commented Aug 16, 2016

I thought this was an actual bug, but in fact in TypeCheckType.cpp, we resolve function types differently if they appear inside another function context. This seems inconsistent and weird. It would be better to allow @escaping on type alias types, as Jordan said.

@swift-ci
Copy link
Collaborator Author

@swift-ci swift-ci commented Aug 16, 2016

Comment by David Grove (JIRA)

The thing that seemed broken to me is that whether a parameter's type is declared with or without using a typealias impacts whether or not the parameter gets the default @NoEscape.

typealias _swift_data_applier = (Int) -> Void
func bogus_error(_ block: _swift_data_applier) { block(10) }
func works_fine(_ block: (Int) -> Void) { block(10) }

The block parameter for bogus_error is considered to be @escaping, but the one for works_fine is considered to be @NoEscape. I would have expected both to be @NoEscape.

@slavapestov
Copy link
Member

@slavapestov slavapestov commented Aug 16, 2016

Yeah, we discussed this today and should have a fix soon. This is definitely a bug.

@swift-ci
Copy link
Collaborator Author

@swift-ci swift-ci commented Aug 23, 2016

Comment by David Grove (JIRA)

fix confirmed.

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

No branches or pull requests

3 participants