<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">In general, any case where you go from immediate evaluation to lazy/delayed evaluation. That change might not be the most frequent, but in my opinion, public interfaces should be as forward compatible as possible.<div class=""><br class=""></div><div class="">Assuming that the closure escapes is always safe and the only difference that I know of is that you need to prefix member accesses with self. I'm not part of it, but there's also a non-negligible group of people who apparently always use self and who would not find any benefit, but still get the forward compatibility downsides, if closures were @noescape by default.<div class=""><div class=""><div class=""><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; line-height: normal; border-spacing: 0px;">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 20 déc. 2015 à 13:05:40, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><br class=""><br class="">Sent from my iPad</div><div class=""><br class="">On Dec 20, 2015, at 10:21 AM, Félix Cloutier <<a href="mailto:felixcca@yahoo.ca" class="">felixcca@yahoo.ca</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div class="">@noescape is part of the interface's contract. If you have it for a while (because you had a warning more than because of thoughtful design) then remove it, you're forcing code changes on your clients. I'm not sure it's an appropriate default/warning, at least for public interfaces.</div><br class=""></div></blockquote><div class=""><br class=""></div><div class="">I'm trying to think of examples where you would change this in scenarios that don't already impact clients. A change from synchronous to asynchronous or vice versa is the main example I can think of and that definitely impacts clients (at least when going from sync to async).</div><div class=""><br class=""></div><div class="">Do you have any examples of where you would reasonably change the escaping behavior without an impact to client code other than the escaping change?</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; font-family: 'Lucida Grande'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-stroke-width: 0px;">Félix</span>
</div>
<br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 20 déc. 2015 à 11:14:51, ilya via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div style="white-space:pre-wrap" class="">> If we don’t change the default maybe we should at least add a warning when you *could* add @noescape but didn’t. A lot of folks are likely to leave it off when they should really be adding it.<br class=""><br class="">I like this idea. We have a warning for variables that can be made into let, so why not this? </div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Sun, Dec 20, 2015 at 18:50 Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
> On Dec 19, 2015, at 7:51 PM, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
> -1<br class="">
><br class="">
> The standard library is not representative of how closures are commonly used. Notably, the standard library never executes anything asynchronously (an extremely common use of closures in apps), doesn't ever hold closures that are triggered later by a separate event (e.g. NSNotificationCenter observing, or UIAlertView handlers, or any third-party solution for block-based target/action replacement), no timers, no completion handlers, etc. The only constructs in the standard library that come to mind that would need escaping closures are lazy sequence operations and AnySequence (I haven't actually looked to see if there are any others). But nearly all uses of closures in UIKit require escaping, nearly all uses of closures in libdispatch require escaping, and I wager that nearly all uses of closures in application code require escaping.<br class="">
<br class="">
Those are fair points. The right place to look is in application code so my skimming of the library was probably not that relevant.<br class="">
<br class="">
The fact that the compiler would tell you when you need @escaping but doesn’t tell you when you could add @noescape is part of what prompted my pitch. If we don’t change the default maybe we should at least add a warning when you *could* add @noescape but didn’t. A lot of folks are likely to leave it off when they should really be adding it.<br class="">
<br class="">
It would be interesting to look at function arguments in application code written in different styles (OO vs mixed vs functional-leaning) and see what the split is for escaping vs non-escaping function arguments.<br class="">
<br class="">
><br class="">
> -Kevin Ballard<br class="">
><br class="">
> On Sat, Dec 19, 2015, at 12:10 PM, Matthew Johnson via swift-evolution wrote:<br class="">
>> @noescape is safer because it does not require thinking about lifetime issues for captured objects. My hunch was that @noescape (or @autoclosure with implies @noescape) is also more common. I had a look through the standard library and this is definitely the case there.<br class="">
>><br class="">
>> What does everyone think about making @noescape the default and introducing @escaping (or something similar) to annotate function arguments that do escape the call stack?<br class="">
>><br class="">
>> Matthew<br class="">
>> _______________________________________________<br class="">
>> swift-evolution mailing list<br class="">
>> <a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
> _______________________________________________<br class="">
> swift-evolution mailing list<br class="">
> <a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=iRI3beHTe3UxYAHTlV3lA38zIPfHMhyuRzgTmGKV6k5sZz-2B0LI7DyOwdqC7tfvELI-2BkQk3emnAnsdGlB7EXvZk2kYwAQrm2vfbprg-2BrsCwpenLLSTGy2TR4OZZc-2BNABrsUBk8asKfb-2BokK71u38qeZ548Zt7Hh5mDkg0AhfinUAkvXhZ803-2BxtXIeQjYlNQMrQIDi9DAFO0-2FDw6t0RYSJMY1r3711Z33Fe4SLSauN7w-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></div></div></div></body></html>