<div dir="ltr">I've created the PR for the proposal at <a href="https://github.com/apple/swift-evolution/pull/373">https://github.com/apple/swift-evolution/pull/373</a>.<div><br></div><div>Thanks again to everyone that has discussed this so far.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 20, 2016 at 8:18 PM, Joe Groff via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Jun 9, 2016, at 4:15 PM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
>><br>
>> On Jun 9, 2016, at 16:10, John McCall <<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>> wrote:<br>
>><br>
>>> On Jun 9, 2016, at 3:43 PM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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.<br>
>><br>
>> 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.<br>
><br>
> 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.<br>
><br>
> (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.)<br>
<br>
</span>This hardly ever goes well. There's a pretty long blood trail of blog posts about this kind of attempted evolution in Javascript land; <a href="http://blog.ometer.com/2011/07/24/callbacks-synchronous-and-asynchronous/" rel="noreferrer" target="_blank">http://blog.ometer.com/2011/07/24/callbacks-synchronous-and-asynchronous/</a> happens to be the one I have on hand this moment.<br>
<br>
-Joe<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Trent Nadeau</div>
</div>