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 <gless...@tffenterprises.com> > wrote: > > Hi Rien, > >> On May 1, 2017, at 08:46, Rien via swift-users <swift-users@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 _______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
