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

[Trent Nadeau]

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 <
swift-evolution at swift.org> wrote:

>
> > On Jun 9, 2016, at 4:15 PM, Jordan Rose via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >>
> >> 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> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Trent Nadeau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160620/f8999b74/attachment.html>