How does closures capture data? - swift

Question

I don't understand this concept that a closure captures data.. Can someone write a sample code using closures that show how data never gets destroyed.. I already read the Apple documents and I'm still confused. And also how does 'unowned' and 'weak' make any difference in a closure...
class TableViewController: UITableViewController {
var allWords = [String]()
var usedWords = [String]()
override func viewDidLoad() {
super.viewDidLoad()
if let allWordsPath = Bundle.main.path(forResource: "start", ofType: "txt"){
if let startWords = try? String(contentsOfFile: allWordsPath){
allWords = startWords.components(separatedBy: "\n")
}else{
allWords = ["Cake"]
}
startGame()
}
navigationItem.rightBarButtonItem = UIBarButtonItem(title: "Make Word", style: .plain, target: self, action: #selector (makeWord))
}
func startGame(){
allWords = GKRandomSource.sharedRandom().arrayByShufflingObjects(in: allWords) as! [String]
title = allWords[0]
usedWords.removeAll(keepingCapacity: true)
}
override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
return usedWords.count
}
override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
let cell = tableView.dequeueReusableCell(withIdentifier: "Word", for: indexPath)
cell.textLabel?.text = usedWords[indexPath.row]
return cell
}
func makeWord() {
let ac = UIAlertController(title: "Add Word", message: nil, preferredStyle: .alert)
ac.addTextField(configurationHandler: nil)
let submit = UIAlertAction(title: "Submit", style: .default){ [unowned self,ac]
(action: UIAlertAction!) in
let answer = ac.textFields?[0]
self.submit(answer: (answer?.text)!)
}
ac.addAction(submit)
present(ac,animated: true)
}
var number = 10
func submit(answer: String){
usedWords.append(answer)
tableView.reloadData()
}
how does unowned work here if we are not explicitly deallocating things..

Answer 1

You should first search for the difference between strong, weak, and unowned. There are PLENTY of answers here on SO about it.
Anyways, in this specific case:
Your closure has this code:
[unowned self,ac]
This is called a "capture list". It indicates the things that should be "captured" by value WHEN THE BLOCK is created. (if you don't specify them here, and you change the value somewhere after the block, the value inside the block would also be changed).
The reason why self is unowned and doesn't require to be deallocated is because unowned means:
"Don't worry about memory management for this variable, it will ALWAYS
have a value for the duration of my closure"
So, going back to unowned self, the reason you should declare weak or unowned the self variable from a closure is because if not you would create a retain cycle. Things can't be deallocated as long as something is referencing them. So in this case, your TableViewController is keeping your closure alive, and your closure is keeping your TableViewController alive. So because they are referencing each other none of them can get deallocated properly. -> Memory Leak
So we can conclude that self has to either be weak or unowned. For all intents and purposes in this example they are exactly the same. They both serve the purpose of "breaking the retain cycle" by removing the ability of the closure to keep self alive. So who will dealloc self you ask? your closure doesn't care. But think outside your closure. Your closure is being called by your TableViewController, so since there's no weird things going on here we can safely assume that, if there is an alert being shown it must definitively be shown over your TableViewController. So once you dismiss the alert or whatever, your TableViewController will keep working as usual. One you dismiss your TableViewController though, self WILL be deallocated (since the closure is referencing it as unowned), but by this point there is no way the alert is being shown. If you however do some weird things that make your TableViewController be dismissed WHILE the alert is still being shown, then once the user "submits" your app will crash. BECAUSE by declaring your variable unowned you basically made a promise to your closure that it wouldn't have to worry about the self entity, as it would always exist as long as your closure was alive.

Answer 2

Check this out. I'm creating 2 objects of the same kind. One has a reference to a closure that retains itself, so even if the function that created it goes out of scope, the object and the closure retain each other and never get released. The second object's closure has a weak reference to the object, and so when the object creating function goes out of scope, the reference count is 0, and when it gets released it releases the closure as well.
import UIKit
import XCPlayground
XCPlaygroundPage.currentPage.needsIndefiniteExecution = true
class B {
deinit {
print("\(name) deinit")
}
var name: String
init(name: String) {
self.name = name
}
var zort: (() -> ())?
func someMethod() {
print("")
}
}
func createStuffThatNeverGoesAway() {
var b: B = B(name: "bad");
b.zort = {
b.someMethod()
}
}
func createStuffThatGoesAway() {
var b: B = B(name: "good");
b.zort = { [weak b] in
b?.someMethod()
}
}
createStuffThatNeverGoesAway()
createStuffThatGoesAway()
Output:
good deinit