CODEWITHSUNDEEP
swiftmemory-leaksclosures
mfaani
mfaani

Reputation: 36287

Why do we need a weakSelf for functions/methods within closures?

Reading my own answer. I fully understand why we need a weakSelf for members/properties. They could create memory cycles. But properties have a memory location. Do functions also have memory locations?! I mean isn't a function something just happens on the go? If so is the memory location type any different from a property location?

If I don't refer using self I get this error.

Call to method 'alertFunc' in closure requires explicit 'self.' to make capture semantics explicit

which is slightly different from:

Reference to property 'window' in closure requires explicit 'self.' to make capture semantics explicit

My code is as follows:

let another = UIAlertAction(title: "Log", style:UIAlertActionStyle.Default){action in  
 logAction ()

 }

private func logAction () {

print("health")

}

Upvotes: 3

Views: 821

Answers (2)

mfaani
mfaani

Reputation: 36287

credit to iOS nerds I know from a meetup

tl;dr you need to use self for instance methods, but don't need it for class methods. A class may have many instances, but it can only have one declaration of itself (which also contains its type/class/static functions).

Why error occurs 1: Bare in mind the alertFunc could have had a reference to a property.

It could have been : 

private func logAction () {

    print("someProperty = \(self.someProperty)")

}

So, in this case it's obvious that you are eventually referencing a property.

Why error occurs 2: Even if you don't have a reference to self within your function, still because you wrote it as an instance method, the self is implicitly passed on. But, we don't see!

An instance method is really just syntactic sugar for a function that takes an instance for the first parameter, which is self passed automatically.

Under the hood it may look something like this :

private func alertFunc (_ instance: MyType) {

    print("someProperty = \(instance.someProperty)")

}

// and actually the call to it *may* look something like this:

MyType.someFunc(self)

We never see the self being passed! It's a syntactic sugar that deceives us.

So, if your method does not use self internally (i.e. doesn't rely on the state of the instance in any way) then it's actually probably best to make it a static/type/class method or free function.

Alternative1: use a free function.

class someClass {

    ...

}

func freeFunc {
    print("Hi this is a free function, written outside the scope of any class...")
}

And then within your closure you call it using freeFunc()

Alternative2: Use a class function.

class someClass {

    ...

     class private func alertFunc() {
          print("Hi this was a class function, see the class at the beginning of the func definition")
     }
 }

And then within your closure you call it using yourClassName.alertFunc()

But, why is it that class functions don't create memory cycles but instance functions do? I'm glad you asked:

For instance mehtods, for each instance that you reach out to, there is a new memory location and generate a new memory cycle which would persist deallocations.

For class methods, for each time you reach out to the class/type methods you reach out to the same class/type method, and while you persist that class method, you won't be creating it over and over, it is only created once and done!

In objective-C (and C++) type methods:

When the app starts up, the system can fairly safely just pre-allocate ALL the instructions for those type methods into memory along with their class pointers so there’s little to no overhead calling those over and over and over again.
I imagine swift is doing the same thing

Upvotes: 3

newacct
newacct

Reputation: 122439

When you write logAction(), it implicitly means self.logAction(). (Methods are called on some instance; when you don't specify, it defaults to self.) So you are using self inside the closure, which means the closure captures self, and whether it captures a strong or weak reference has memory management implications.

Upvotes: 2

Related Questions