I've created the PR for the proposal at https://github.com/apple/swift-evolution/pull/373.
Thanks again to everyone that has discussed this so far. On Mon, Jun 20, 2016 at 8:18 PM, Joe Groff via swift-evolution < [email protected]> wrote: > > > 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 > -- Trent Nadeau
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
