<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I don’t think there’s any symmetry break. I would argue that forced-unwrapping is rarely a best-practice. The swifty way would be to always use guard let and if let for optionals. Looking through the Swift Programming Language book, the only examples of “<font face="Menlo" class="">if x != nil</font>” I can find just print some explanatory text (and even then I’d argue it’s better to use <font face="Menlo" class="">if let _ = x</font>). <br class=""><div class="">
--<br class="">Chris McIntyre<br class=""><br class=""><br class=""><br class="">
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On May 2, 2017, at 2:05 AM, Rien via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Thanks Guillaume,<br class=""><br class="">Interesting: this is a kind-of symmetry break between optionals and weak references.<br class="">I.e. most (inexperienced?) programmers will see a strong similarity between weak references and optionals.<br class="">And for a lot of use cases they do indeed behave similar.<br class="">But for weak references I think the guideline should be: Never ‘force-unwrap’ it.<br class="">Maybe this should be mentioned in the swift guide?<br class="">Maybe even include a warning in the compiler for this?<br class=""><br class="">Regards,<br class="">Rien<br class=""><br class="">Site: <a href="http://balancingrock.nl" class="">http://balancingrock.nl</a><br class="">Blog: <a href="http://swiftrien.blogspot.com" class="">http://swiftrien.blogspot.com</a><br class="">Github: <a href="http://github.com/Balancingrock" class="">http://github.com/Balancingrock</a><br class="">Project: <a href="http://swiftfire.nl" class="">http://swiftfire.nl</a> - A server for websites build in Swift<br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On 01 May 2017, at 23:26, Guillaume Lessard <<a href="mailto:glessard@tffenterprises.com" class="">glessard@tffenterprises.com</a>> wrote:<br class=""><br class="">Hi Rien,<br class=""><br class=""><blockquote type="cite" class="">On May 1, 2017, at 08:46, Rien via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:<br class=""><br class="">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.<br class=""><br class="">Now I am wondering: how does the compiler know that [weak self] is referenced?<br class=""></blockquote><br class="">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.<br class=""><br class=""><br class=""><blockquote type="cite" class="">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.<br class=""></blockquote><br class="">It does not.<br class=""><br class="">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.<br class=""><br class="">You could read Mike Ash’s description at <<a href="https://www.mikeash.com/pyblog/friday-qa-2015-12-11-swift-weak-references.html" class="">https://www.mikeash.com/pyblog/friday-qa-2015-12-11-swift-weak-references.html</a>>. 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.<br class=""><br class=""><br class=""><blockquote type="cite" class="">But when a job is executing it has no control over the exclusive rights to [weak self].<br class=""><br class="">I.e. [weak self] may be nilled by an outside event in the middle of say:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if self != nil { return self!.myparam }<br class=""><br class="">The if finding [weak self] non nil, but the return finding [weak self] as nil<br class=""><br class="">Is that correct? i.e. should we never use the above if construct but always:<br class=""></blockquote><br class="">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.<br class=""><br class="">The proper way is<br class=""><br class="">if let myref = self { return myref.myparam }<br class=""><br class="">(or the equivalent guard.)<br class="">That’s safe.<br class=""><br class="">Cheers,<br class="">Guillaume Lessard<br class=""></blockquote><br class="">_______________________________________________<br class="">swift-users mailing list<br class=""><a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-users<br class=""></div></div></blockquote></div><br class=""></body></html>