[weak self] and [unowned self] are used to solve the problem of Strong
Reference Cycles Between Class Instances
<https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/AutomaticReferenceCounting.html>
.
If you can grantee self won't be nil during the life time, you should use
`unowned self` instead of `weak self`. If you can't grantee that, you
should use `weak self` and `return self?.myparam ?? 42`. I don't think
using ` if self != nil { return self!.myparam }` is a good idea. The reason
is said by you already.
Zhaoxin
On Mon, May 1, 2017 at 11:42 PM, Dennis Weissmann via swift-users <
swift-users@swift.org> wrote:
>
> On May 1, 2017, at 5:32 PM, Rien <r...@balancingrock.nl> wrote:
>
>
> On 01 May 2017, at 16:59, Dennis Weissmann <den...@dennisweissmann.me>
> wrote:
>
>
> On May 1, 2017, at 4:46 PM, 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?
>
> 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.
>
> 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:
>
> return self?.myparam ?? 42
>
>
> Yes, as you said, you never know when self will be nilled out, that's why
> you need to create a (temporary) strong reference to it, work on it, and
> when the block returns, your strong reference is released and self either
> goes away immediately (incase it was released elsewhere after the local
> binding to a strong variable and no other objects had a strong reference to
> it) or it will stay as long as no other object holds a strong reference to
> it.
>
> When the closure is more involved than a view lines, I often do a guard
> let `self` = self else { return } to conveniently work with a strong self
> inside the rest of the closure.
>
>
> I was aware of that practise (use it myself) but I was not sure if it
> would always work.
> I.e. I have not found it documented that
> let strongSelf = self
> will actually retain ‘self’ an not create a strong reference to an
> intermediate reference to self.
>
> It makes sense though, otherwise there would be massive failures ‘out
> there’. ;-)
>
>
> Yes :) local variables (as others too) are strong by default. If you want
> them weak (you should very rarely need that though) you have to explicitly
> mark them weak.
>
> will actually retain ‘self’ an not create a strong reference to an
> intermediate reference to self.
>
>
> Isn't that the same? I might misunderstand you but they would both
> reference the same object, no? So in the end the retain message would be
> sent to the same object, wouldn't it?
>
> Thanks,
> Rien.
>
>
> 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
>
>
>
>
>
>
> _______________________________________________
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
> - Dennis
>
>
> - Dennis
>
>
> _______________________________________________
> 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
