> On Jun 9, 2016, at 4:15 PM, Jordan Rose via swift-evolution > <[email protected]> wrote: > >> >> 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]> 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.)
This hardly ever goes well. There's a pretty long blood trail of blog posts about this kind of attempted evolution in Javascript land; http://blog.ometer.com/2011/07/24/callbacks-synchronous-and-asynchronous/ happens to be the one I have on hand this moment. -Joe _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
