> On Jun 9, 2016, at 16:10, John McCall <[email protected]> wrote:
>
>> On Jun 9, 2016, at 3:43 PM, Jordan Rose via swift-evolution
>> <[email protected] <mailto:[email protected]>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
