[swift-evolution] [Proposal] Make non-escaping closures the default

[Jordan Rose]

> On Jun 9, 2016, at 16:10, John McCall <rjmccall at apple.com> wrote:
> 
>> On Jun 9, 2016, at 3:43 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> I'm against this for library evolution reasons: if someone releases a version of their library that has a non-escaping closure and later discovers it needs to be escaping, they can't change it.
>> 
>> IIRC the counterpoint to this is that people were probably implicitly relying on it being non-escaping already, and that there aren't many cases where you'd want to do this anyway.
> 
> Right.  APIs are already semantically constrained in how they're allowed to use their closure arguments.  Closure arguments inject arbitrary code, with arbitrary data access, into the callee; as a rule, the caller must know how the callee intends to use the closure, or its semantics will be grossly violated.  You can't re-implement an existing API that always synchronously sub-invokes a closure to instead call the closure asynchronously or concurrently because it is completely reasonable for the caller to pass a closure that relies on being called synchronously or from at most one thread at once and/or within a fixed range of time.  For example, the closure may modify a captured local variable, or it may it use a network connection that will be closed after the API returns.  APIs that want to do this sort of thing have to reserve the right to do that (and even then, they may have binary compatibility limitations), in which case it is totally reasonable to expect them to express that in the type.

I don't buy this. If someone publishes an API that executes something on the current thread today and on a background queue tomorrow, that's totally fine if they never promised it would execute on a particular thread. If a client accidentally assumes an implementation detail is part of the interface, that's their fault, and always has been…though the library author might decide to continue supporting their use in the future in the interest of not making waves.

(Escaping/non-escaping by default doesn't affect this, by the way, but by the same token this argument doesn't really affect escaping/non-escaping by default.)

Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160609/719f7bab/attachment.html>