<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=""><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><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 20, 2016, at 21:32 , Timothy Wood via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class="">In preparation for writing a proposal, I wanted to solicit any feedback and general level of interest on addressing SR-842, which proposes modifying ObjectiveC.autoreleasepool to allow a potentially `throw`ing body via a `rethrows` annotation. I have a branch with the very simple change applied and a test. However, Dmitri Gribenko pointed out that it would be even better if the signature was amended to allow for a generic return type:<br class=""><br class=""> public func autoreleasepool<Result>(@noescape code: () throws -> Result) rethrows -> Result<br class=""><br class="">It isn’t clear to me whether it is possible for a wrapper to be written that adds rethrow, since the function needs to compile under the assumption that the passed block does not throw. So, something like this doesn’t actually compile.<br class=""><br class=""> func autoreleasepool_generic<ResultType>(@noescape code: Void throws -> ResultType) rethrows -> ResultType {<br class=""><br class=""> // or some Result enum...<br class=""> var result:ResultType?<br class=""> var error:ErrorProtocol?<br class=""><br class=""> autoreleasepool {<br class=""> do {<br class=""> result = try code()<br class=""> } catch let e {<br class=""> error = e<br class=""> }<br class=""> }<br class=""><br class=""> if let result = result {<br class=""> return result<br class=""> }<br class=""><br class=""> // Doesn't work, since in the case that `code` doesn't throw, the whole function can't.<br class=""> throw error!<br class=""> }<br class=""><br class="">Is there a way I’m missing to write a rethrows wrapper around autoreleasepool that would provide a fair comparison?<br class=""><br class="">At any rate, it seems much nicer to be able to do:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>let value = try autoreleasepool {…}<br class=""><br class="">than to have a bunch of boilerplate at the call site, or for everyone to figure out how to write their own wrapper.<br class=""><br class="">Some other questions for feedback that I came across while looking into this:<br class=""><br class="">- Since the API is already changing, should the `code` parameter be renamed to `body`? The rest of stdlib uses `body` frequently and never uses `code` as far as I can see.<br class="">- Should the name of the generic argument be something like ‘Result’ (which might conflict with a enum that holds a value-or-error) or ‘ResultType` (which might conflict with a protocol in 2.2 land, but less so in 3.0 maybe?), or something else?<br class=""><br class="">Thanks!<br class=""><br class="">-tim<br class=""><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></body></html>