vincent-pradeilles/weakable-self

A Swift micro-framework to easily deal with weak references to self inside closures

WeakableSelf

Context

Closures are one of Swift must-have features, and Swift developers are aware of how tricky they can be when they capture the reference of an external object, especially when this object is self.

To deal with this issue, developers are required to write additional code, using constructs such as [weak self] and guard, and the result looks like the following:

service.call(completion: { [weak self] result in
    guard let self = self else { return }
    
    // use weak non-optional `self` to handle `result`
})

Purpose of WeakableSelf

The purpose of this micro-framework is to provide the developer with a helper function weakify that will allow him to declaratively indicate that he wishes to use a weak non-optional reference to self in closure, and not worry about how this reference is provided.

Usage

Using this weakify function, the code above will be transformed into the much more concise:

import WeakableSelf

service.call(completion: weakify { strongSelf, result in    
    // use weak non-optional `strongSelf` to handle `result`
})

weakify works with closures that take up to 7 arguments.

Installation

Requirements

• Swift 4.2+
• Xcode 10+

CocoaPods

Add the following to your Podfile:

pod "WeakableSelf"

Carthage

Add the following to your Cartfile:

github "vincent-pradeilles/weakable-self"

weakable-self's Issues

A same one is found

I know that there is a repeated wheels Strongify written by krzysztofzablocki, which encapsulates the strong-weak-dance with more than one object.

Order issue

Hi!
Thanks for this great implementation!

Although, its usage really looks like another operator that can be found in RxSwiftExt (I don't know if you ever heard of if ) and the order in the arguments isn't consistent between the two methods

for now it takes two parametters, first the passed parameter and then the self which results in a call like this :

   .subscribe(onNext: weakify { data, strongSelf in
             strongSelf.doSomething(with: data)
            })

I find it kind of awkward considering that when we use .withUnretained(self) the order is reversed.

.withUnretained(self)
.subscribe(onNext: { strongSelf, data in
             strongSelf.doSomething(with: data)
            })

Also in the general case in closures the compiler enforces the [weak/unretained self] to be before the arguments of the closure

.subscribe(onNext: { [unretained self] data in
             self.doSomething(with: data)
            })

what do you think about changing the order in the new method ?
If you agree I can obviously make a pull request with the changes :)

Cheers!