-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
> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
