> On Mar 23, 2016, at 10:36 PM, Chris Lattner <clatt...@apple.com> wrote:
> 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.

If this is the plan, then I’d agree that adding a return value would not be 
good since it would make that “inlining” more of a breaking change. But, to 
some extent that ship has already sailed:

        func f() {
                autoreleasepool {
                        if (somethingWithLotsOfAutoreleasedObjects()) {
                                return;
                        }
                        somethingImportant()
                }
        }

If `autoreleasepool` is turned into a statement instead of a function, the 
meaning of existing code will silently change in possibly disastrous and hard 
to detect ways. Is there a plan in place to deal with this? The only idea that 
occurs to me would be to leave `autoreleasepool` as is for a transitional time, 
deprecated, and add a statement with a new name. Though, if a newly named 
statement were to be added, then we’re back to being able to leave 
`autoreleasepool` as a function with a return value and error =)

With the `rethrow`/`throws` annotation, the migration would be easier since the 
compiler would catch `try autorelease {...}` as invalid and the extra `try` 
could be removed.

Either way, I’m most interested in the `rethrow`/`throws` annotations since 
passing a value and error back out are most error-prone part, and since it 
isn’t possible to add in a wrapper. The return value would be possible to 
re-add in a wrapper, of course.

-tim

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to