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

[Jordan Rose]

-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


> On Mar 20, 2016, at 21:32 , Timothy Wood via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 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:
> 
>  public func autoreleasepool<Result>(@noescape code: () throws -> Result) rethrows -> Result
> 
> 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.
> 
>  func autoreleasepool_generic<ResultType>(@noescape code: Void throws -> ResultType) rethrows -> ResultType {
> 
>    // or some Result enum...
>    var result:ResultType?
>    var error:ErrorProtocol?
> 
>    autoreleasepool {
>      do {
>        result = try code()
>      } catch let e {
>        error = e
>      }
>    }
> 
>    if let result = result {
>      return result
>    }
> 
>    // Doesn't work, since in the case that `code` doesn't throw, the whole function can't.
>    throw error!
>  }
> 
> Is there a way I’m missing to write a rethrows wrapper around autoreleasepool that would provide a fair comparison?
> 
> At any rate, it seems much nicer to be able to do:
> 
> 	let value = try autoreleasepool {…}
> 
> than to have a bunch of boilerplate at the call site, or for everyone to figure out how to write their own wrapper.
> 
> Some other questions for feedback that I came across while looking into this:
> 
> - 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.
> - 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?
> 
> Thanks!
> 
> -tim
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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