[SR-2907] 3.0.1p2: @escaping of closure arrays Created: 10 Oct 2016  Updated: 11 Oct 2016  Resolved: 11 Oct 2016

Status: Resolved
Project: Swift
Component/s: Compiler

Type: Bug Priority: Medium
Reporter: Helge Heß Assignee: Michael Ilseman
Resolution: Done Votes: 0
Labels: 3.0Regression
Environment:

Linux TrustySwift 4.2.0-27-generic #32~14.04.1-Ubuntu SMP Fri Jan 22 15:32:26 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Welcome to Swift version 3.0.1 (swift-3.0.1-PREVIEW-2). Type :help for assistance.


Attachments: File TestCallbacks.swift    
Radar URL: rdar://problem/28701872

 Description   

Swift 3.0.1 Preview 2 Regression
The compiler throws an error when arrays or varargs of closures are marked as @escaping:

helge@TrustySwift:~/dev/Swift/tmp$ swift TestIt.swift
TestIt.swift:8:28: error: @escaping attribute may only be used in function parameter position
  func add(callbacks cbs: @escaping Callback...) {
                          ~^~~~~~~~~~~~~~~~

Example which works with Swift 3.0.0:

    public typealias Middleware =
                   ( IncomingMessage, ServerResponse, @escaping Next ) -> Void
    
    public func connect(middleware: @escaping Middleware...) -> Connect {
      let app = Connect()
      for m in middleware { _ = app.use(m) }
      return app
    }

I can remove the @escaping and it compiles just fine with 3.0.1p2, which I think is wrong. And as a matter of fact it breaks compilation with Swift 3.0.0:

/Users/helge/dev/Swift/Noze.io/Sources/connect/Module.swift:21:17: error: invalid conversion from non-escaping function of type '(IncomingMessage, ServerResponse, @escaping (Any...) -> ()) -> ()' to potentially escaping function type 'Middleware' (aka '(IncomingMessage, ServerResponse, @escaping (Any...) -> ()) -> ()')
    _ = app.use(m)
                ^
                  as! Middleware

Summary: @escaping needs to be allowed again on array parameters or vararg parameters.

P.S.: This is made worse by the fact that you can't even workaround it via:

#if swift(>=3.0.1)

but that may be another bug...



 Comments   
Comment by Jordan Rose [ 10 Oct 2016 ]

"escaping" is a property of parameters, but in these cases the closure type isn't being used as a parameter—it's a generic argument. Just like you can't put escaping in Box<() -> Void>, it's also not accepted for Optional or Array. So 3.0.1 is the expected behavior.)

(We probably want to consider making an exception for Optional, but that would be a much more drastic source-breaking change, because it would force everyone to re-audit their optional closure parameters.)

Comment by Jordan Rose [ 10 Oct 2016 ]

cc Michael Ilseman

Comment by Helge Heß [ 10 Oct 2016 ]

I think it is quite easy to argue that it is in fact a property of parameters in this case:

func doIt(cbs: @escaping MyCallbackType...)

I can kinda see your point for this:

func doIt(cbs: @escaping [ MyCallbackType ])

This implies @escaping because the types are already part of a collection? Fine for me.

Neither changes the fact that the 3.0.1change is a major source breaking change to Swift 3.0. And that should not be
Particularly because source code can't even safeguard against the issue, see SR-2908.

P.S.: Maybe a solution is to change the hard error into a fix-it-note in this case? (just ignore the @escaping if it is implied ...)

Comment by Michael Ilseman [ 10 Oct 2016 ]

cc Slava Pestov

Comment by Jordan Rose [ 10 Oct 2016 ]

Actually, reopening because of the source-breaking aspect.

Comment by Jordan Rose [ 10 Oct 2016 ]

I don't think we can leave around warnings on backwards-compatibility code either, not without any way to silence warnings. If we care about this case being compatible with 3.0.0, we probably just need to accept both until Swift 4.

Comment by Slava Pestov [ 10 Oct 2016 ]

Hi +helge, we consider the 3.0.0 behavior a bug – the proposal was not implemented correctly. While it is unfortunate that the behavior changed in 3.0.1, the new behavior is more correct and in the spirit of the feature we wanted to implement. Why is it important to maintain source compatibility between 3.0.0 and 3.0.1? Can you just not use 3.0.0?

Comment by Michael Ilseman [ 10 Oct 2016 ]

The problem here is that they can't. They can't support both language versions in a library simultaneously, as neither is valid syntax for the other.

Comment by Michael Ilseman [ 10 Oct 2016 ]

I'm working on a potential fix.

Comment by Slava Pestov [ 10 Oct 2016 ]

Why not just say the library requires 3.0.1?

Comment by Michael Ilseman [ 10 Oct 2016 ]

Because maybe they want to be compatible with 3.0 and have 3.0 users who can migrate to 3.0.1 at their convenience. If it's a library that has users, this would require a coordinated change of the library and all users at the same time, otherwise there's breakage.

I agree that fixing this makes it worse for 3.0.1 and later code, as it gives the false impression that having `@escaping` on a var arg closure changes semantics. This has to be carefully weighed.

Comment by Myke Olson [ 10 Oct 2016 ]

Swift Sync System create

Comment by Helge Heß [ 10 Oct 2016 ]

I don't want to troll, but I find it pretty hard to discuss the core issue :-> Do you really consider it OK to have source code incompatibilities between a 3.0.0 and 3.0.1 version. I mean there is a 3 in front and the thing being bumped is the sub minor.

It doesn't really matter that much, but my specific issue is that:
a) I want macOS people use the standard Xcode and not some preview release. So that is 3.0.0.
b) but tuxOS people need to use 3.0.1pr2 because libdispatch is badly b0rked in 3.0.0
c) a+b would still be OK for me, but due to SR-2908 I can't even hack around the language difference (because quite frankly `#if swift(=>maj.min)` anticipated that there would be no language differences in subminors

Personally I can also wait for Xcode 8.0.1 and the 3.0.1 Linux release. Though I (and presumably everyone else) was really hoping that this 'you have to use this specific Swift 3 version' madness would end with Swift 3.0.
Right now I'm still telling newcomers to stick to Swift 2.3 because I can't make a 3.0 release yet, even accepting that Linux itself would require a preview version

Comment by Slava Pestov [ 10 Oct 2016 ]

Helge Heß I think you're right, and we should try to maintain compatibility here. Michael Ilseman is working on a fix.

Comment by Michael Ilseman [ 10 Oct 2016 ]

https://github.com/apple/swift/pull/5217 is the PR for the 3.0 release family. There's no guarantee that it will be taken, as that will need to be carefully determined, as it does slightly pessimize the developer experience with 3.0.1 and later.

Comment by Michael Ilseman [ 11 Oct 2016 ]

This got merged into the swift-3 branch.

Generated at Wed Feb 21 09:19:56 CST 2018 using JIRA 7.3.4#73015-sha1:a262b3457b3605f12635df4b0a0c3dc71d631a1e.