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 “if x != nil” I can find just print some explanatory text (and even then I’d argue it’s better to use if let _ = x). -- Chris McIntyre
> On May 2, 2017, at 2:05 AM, Rien via swift-users <swift-users@swift.org> > wrote: > > 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
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
