[SR-2907] 3.0.1p2: @escaping of closure arrays #45501
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
Additional Detail from JIRA
Swift 3.0.1 Preview 2 Regression
Example which works with Swift 3.0.0:
I can remove the
P.S.: This is made worse by the fact that you can't even workaround it via:
but that may be another bug...
The text was updated successfully, but these errors were encountered:
"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
(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 Helge Heß (JIRA)
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 :-)
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 ...)
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?
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 Helge Heß (JIRA)
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:
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.