<div dir="ltr">I sympathize with the problem statement, but I wonder if we should instead be considering ways of allowing control-flow statements (break, continue, return) to work from inside @noescape closures.<div><br></div><div>Another possible solution would be to expose __pushAutoreleasePool() and __popAutoreleasePool() as public API. This would also allow more careful manual use of autorelease pools (for instance, draining the pool after every 5 loop iterations, rather than every iteration).</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div>Jacob<br></div></div></div></div>
<br><div class="gmail_quote">On Fri, Jan 8, 2016 at 5:32 PM, Charles Srstka via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">When dealing with Objective-C code, especially older code that predates ARC, much of which can be found in standard Apple frameworks such as Foundation and AppKit, one is sure to generate a lot of autoreleased objects. In cases where a lot of autoreleased objects are generated inside a loop, this can lead to excessive memory usage unless one puts the body of the loop inside an autorelease pool. Traditionally, this would have been done in Objective-C like so:<br>
<br>
for id foo in bar @autoreleasepool {<br>
    …<br>
}<br>
<br>
The Swift equivalent of this would be:<br>
<br>
for foo in bar {<br>
    autoreleasepool {<br>
        …<br>
    }<br>
}<br>
<br>
However, due to Swift’s “autoreleasepool” function being implemented via a closure, this introduces a new scope, causing many forms of flow control not to work. Most problematically, the ‘break’ and ‘continue’ statements no longer function, since the control flow is no longer considered to be inside a loop, but there are other consequences too, such as not being able to early-return out of the method, or throw an error. The latter issue can be solved by writing a custom version of the “autoreleasepool” function that takes a throwing closure and rethrows it, but I can’t think of any workaround for the lack of “break” and “continue” with the current system other than breaking up the loop body into lots of smaller autoreleasepool statements.<br>
<br>
I propose adding an @autoreleasepool attribute that could be added to loops, like so:<br>
<br>
@autoreleasepool for foo in bar {<br>
        ...<br>
}<br>
<br>
This would wrap the loop body inside an autorelease pool, without disabling the usual flow control statements.<br>
<br>
What do you think?<br>
<br>
Charles<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div><br></div></div>