[swift-evolution] Update the signature of ObjectiveC.autoreleasepool [SR-842]

[Timothy J. Wood]

> On Mar 21, 2016, at 9:37 AM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> -1 for the signature change. The most common case of autoreleasepool does not return a value and has a multi-statement body that prevents the result type from being inferred. This needs to continue to work:
> 
> autoreleasepool {
>   foo()
>   bar()
> }
> 
> 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.)
> 
> Jordan
> 

Thanks for pointing this case out.

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):

	https://gist.github.com/tjw/4904ac82f84adf9f2292

Of course, if anyone sees cases that I missed checking I’d appreciate notes on that.

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.

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.

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!)

Thanks,

-tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160321/e622443f/attachment.html>