> On Mar 21, 2016, at 9:37 AM, Jordan Rose <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
