Allowing explicit @escaping for optional closures in function parameters

[gwendal.roue (Gwendal Roué)]

The regular evolution process usually rejects breaking changes, unless they are very strongly motivated.

In a normal situation, I wouldn't have bet a dime on the pitch.

But we have received some encouragement from a member of the Swift core team:

@John_McCall

We are not going to invent a whole new language mechanism for expressing parameter function optionality. It should be quite straightforward to extend escape analysis to optional parameter functions and allow them to be explicitly marked as @escaping or @nonEscaping (or however we want to spell that). We can also investigate changing the default language rule for optional parameter functions so that it's consistent for different optionalities, but that's a separable question.

Two points in his message:

The introducing of @escaping or @nonEscaping for optional closures should be easily accepted. It does not create any breaking change, as long the default rule for optional parameter closures keeps them @escaping.

He also suggest we investigate changing the default language rule for optional parameter closures. To make them @nonEscaping by default. There lies the breaking change.

And it's quite likely he did not miss it. It's a personal interpretation, of course, and it makes me optimistic. But as I tried to explain in my previous message, a breaking change is just not a matter of implementing it. We also have to plan the transition, and this plan is part of the proposal.