[swift-users] weak self

[Chris McIntyre]

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 at 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 <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
> 
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170502/31c3fd84/attachment.html>