> On Mar 21, 2016, at 9:37 AM, Jordan Rose via swift-evolution > <[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.)
I understand that Jordan withdrew his objection later (because no overload is required) but it still isn't clear to me that autoreleasepool should return a value. Here’s my thought process: autoreleasepool is *intentionally* looking like a statement, not an expression. Someday I hope it will be possible to break/continue/return/throw out of a closure, and at that point, it will look exactly like a statement. The problem with adding a return value for this is that (so far) we don’t allow the same thing to ‘do’, ‘if’, ‘switch’ and other statements. I’d argue that autoreleasepool should follow as close as possible in do’s footsteps: if/when we decide to expressionize these statements, at that point should we expressionize autoreleasepool to match. -Chris
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
