What is the equivalent of @autoreleasepool in Swift?

automatic-ref-counting swift nsautoreleasepool

17,177

Solution 1

The syntax is as follows:

autoreleasepool {
  /* code */ 
}

Unfortunately Apple's WWDC 2014 videos no-longer seem to be available. Incase it comes back, it was covered in WWDC 2014 session video number 418 "Improving Your App with Instruments".

The swift documentation doesn't contain anything useful currently. But you can find plenty of good information under the Obj-C Runtime Reference for NSAutoreleasePool and the Advanced Memory Management Programming Guide.

Note: Auto Release Pools are no-longer as relevant today as they were in the past. Modern code should use Automatic Reference Counting which does not use release pools at all. However there's still a lot of legacy code, including in Apple's frameworks, that use auto release pools as of 2021. If you're doing any kind of batch process on images as one example, you probably should be using an autoreleasepool block.

Solution 2

Just FYI, Xcode constructed the full code as follows:

autoreleasepool({ () -> () in
    // code              
})

Guess the parentheses identifies the functions closure.

Solution 3

There is! It's just not really mentioned anywhere.

autoreleasepool {
    Do things....
}

17,177

Author by

Skotch

Updated on June 23, 2022

Comments

Skotch about 2 years

In Swift, I notice there is no @autoreleasepool{} construct, although Swift does use ARC. What is the proper way to manage an autoreleasepool in Swift, or has it been removed for some reason?
Erik about 10 years

It's important to note that the { must be on the same line as the autoreleasepool, otherwise you have to wrap it in ( ). That really irks me to be honest...
Abhi Beckert about 10 years

@SiLo really? That sucks. You should file a bug report.
Cezary Wojcik about 10 years

@AbhiBeckert @SiLo It's not a bug. autorelease is a function that takes a closure as an argument. This is an example of the short-hand closure-as-last-argument syntax.
Erik about 10 years

@CezaryWojcik Right, but why does it matter if I place the { on a new line instead of right after?
Cezary Wojcik about 10 years

@SiLo Since there are no semicolons, if the closure is on the next line, then there isn't a syntactic guarantee that that closure is supposed to be an argument for the function above it. You can see the same thing in JavaScript when you try to do something like return { ... }.
Abhi Beckert about 10 years

@CezaryWojcik ah, that makes sense. Here's a gist explaining it in code: gist.github.com/abhibeckert/2a9006d3f24a0937a932 — basically since there are no semicolons to terminate lines the compiler doesn't have any way to link the two statements together. It's a shame, but probably not avoidable.
Rob almost 10 years

@AbhiBeckert Interestingly, that video says that this is used when "working with Objective-C". In my experimentation, it really is only needed when dealing with Objective-C objects (inc Cocoa classes), but not pure Swift objects. I'm digging around to see if I can find some documentation of this (other than the parenthetical reference in this video) and I'm not finding anything. Have you found any document about this autorelease function (and its use with Objective-C vs Swift objects)?
Abhi Beckert almost 10 years

@Rob I haven't looked into it myself. Autorelease pools aren't needed very often, and my experience any time you do need to work with autorelease pools you should be working with Apple's lower level C APIs instead of Objective-C. If you need to manage memory manually, you should drop down to a low level language and actually manage it manually. It's entirely plausible Apple simply hasn't implementing anything like auto release in Swift, since the language isn't intended to be used in ways that need it. I'm not surprised it's obj-c only. I bet it works on swift classes subclassing NSObject BTW.
Rob almost 10 years

@AbhiBeckert I'll respectfully disagree that one should go to C APIs just because you need to drain the pool: I'd always stay at the highest possible level of abstraction and they provide us the ability to create our own pools for a reason. And this discussion on Apple's forums makes me think that it's not the case that Swift "hasn't implemented anything like autorelease in Swift", but merely that the now default to +1 objects with transferred ownership now "wherever possible" (which is a cleaner, IMHO) but still support autorelease as needed.
Abhi Beckert almost 10 years

@Rob I agree this in itself is not a reason to drop down to C. However I suspect there is a very high correlation between times when you need to deal with autorelease pools and times when you should be using C instead. I know I've only ever had to deal with autorelease pools when I need to process hundreds of megabytes of data, and in pretty much all these cases I have, eventually, thrown the code out and re-written it in C — autorelease works fine but when you're working with large amounts of memory, often you need to tell the compiler exactly what to do, not just give it a few hints.
bolnad almost 9 years

not sure why anyone de-voted this comment, as he's pointing out that an autorelease pool as far as swift1.2 needs the code to be wrapped in a closure
Kaiserludi almost 9 years

@Cezary and that is one of the reasons, why it has been an extremely bad idea to design another programming language that uses line breaks instead of semicolons to mark the end of a statement - whitespaces that are syntactically significant are one of the most outstanding marks of terrible language design.
Ben Butterworth about 3 years

I couldn't find this video online. It looks like Apple took it down. I also tried the Apple Developer.app from the Mac App Store.
Abhi Beckert about 3 years

@BenButterworth You're right, only a handful of videos from WWDC 2014 are still available. I've updated my answer to include the best available alternative I could find after a quick look.