[swift-users] weak self

[Rien]

Thanks Guillaume,

Interesting: this is a kind-of symmetry break between optionals and weak references.
I.e. most (inexperienced?) programmers will see a strong similarity between weak references and optionals.
And for a lot of use cases they do indeed behave similar.
But for weak references I think the guideline should be: Never ‘force-unwrap’ it.
Maybe this should be mentioned in the swift guide?
Maybe even include a warning in the compiler for this?

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift






> On 01 May 2017, at 23:26, Guillaume Lessard <glessard at tffenterprises.com> wrote:
> 
> Hi Rien,
> 
>> On May 1, 2017, at 08:46, Rien via swift-users <swift-users at swift.org> wrote:
>> 
>> In my code I use a lot of queues. And (very often) I will use [weak self] to prevent doing things when ‘self’ is no longer available.
>> 
>> Now I am wondering: how does the compiler know that [weak self] is referenced?
> 
> The object never knows whether a weak reference to it is being used; in order to be safe you must bind the reference — then you get a strong reference out of it, and that guarantees the object stays alive as long as the strong reference is in scope.
> 
> 
>> I am assuming it keeps a reverse reference from self to the [weak self] in order to ‘nil’ the [weak self] when self is nilled.
> 
> It does not.
> 
> From the perspective of the runtime, weak references are a different type than normal/strong references; what’s important to know here is that getting a strong reference from a weak one is thread-safe. It’s interesting to know that weak references to “dead” objects are nilled out on use, lazily. When a WeakReference is used, the object’s strong reference count is checked, and if that is zero then the WeakReference is nilled out.
> 
> You could read Mike Ash’s description at <https://www.mikeash.com/pyblog/friday-qa-2015-12-11-swift-weak-references.html>. That describes Swift 3 weak references quite well. There’s a newer implementation of reference counting for Swift 4, but the outwardly-visible behaviour is the same.
> 
> 
>> But when a job is executing it has no control over the exclusive rights to [weak self].
>> 
>> I.e. [weak self] may be nilled by an outside event in the middle of say:
>> 
>> 	if self != nil { return self!.myparam }
>> 
>> The if finding [weak self] non nil, but the return finding [weak self] as nil
>> 
>> Is that correct? i.e. should we never use the above if construct but always:
> 
> There is potential for a race on `self`, as the strong reference count could go to zero between the two uses of the weak reference.
> 
> The proper way is
> 
> if let myref = self { return myref.myparam }
> 
> (or the equivalent guard.)
> That’s safe.
> 
> Cheers,
> Guillaume Lessard