<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 21, 2016, at 9:37 AM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">-1 for the signature change. The most common case of autoreleasepool does <i class="">not</i> return a value <i class="">and</i> has a multi-statement body that prevents the result type from being inferred. This needs to continue to work:</div><div class=""><br class=""></div><div class="">autoreleasepool {</div><div class=""> foo()</div><div class=""> bar()</div><div class="">}</div><div class=""><br class=""></div><div class="">If we had a rule to default generic return values to Void if they aren't used then I'd be okay with it, but that'd be a separate proposal. (Providing two overloads may also work; haven't tested it.)</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div></div></div></blockquote></div><br class=""><div class="">Thanks for pointing this case out.</div><div class=""><br class=""></div><div class="">It looks like from a quick check that Swift will allow for two versions of a function that differ in a function parameter return type / throw type, and will pick the right one. At least, this produces what seems like reasonable results in Xcode 7.3b5 with the default snapshot (I’ve not tested with 3.0 yet, but presumably it would be a regression for it to not work there):</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://gist.github.com/tjw/4904ac82f84adf9f2292" class="">https://gist.github.com/tjw/4904ac82f84adf9f2292</a></div><div class=""><br class=""></div><div class="">Of course, if anyone sees cases that I missed checking I’d appreciate notes on that.</div><div class=""><br class=""></div><div class="">This does promote to the `rethrows` version if there is any return type, but does so w/o compile warnings/errors, but I’m presuming that this doesn’t add undue runtime performance overhead. In my experience, call sites that are explicitly using pools are allocation-heavy (kinda the whole point =) and any micro-benchmark change here wouldn’t be significant.</div><div class=""><br class=""></div><div class="">I can amend the proposed API change with the addition of a new version of `autoreleasepool` that adds a return value and rethrows annotation and leaves the Void -> Void version.</div><div class=""><br class=""></div><div class="">As a side note, checking one of our products 28 of 123 uses of @autoreleasepool in ObjC-land are things that would benefit from a return value. Other code bases may differ, but it seems like a significant amount of code could be cleaned up (but an even bigger chunk wouldn’t want to deal with the implicit non-Void return case!)</div><div class=""><br class=""></div><div class="">Thanks,</div><div class=""><br class=""></div><div class="">-tim</div><div class=""><br class=""></div></body></html>