> On 01 May 2017, at 17:42, Dennis Weissmann <den...@dennisweissmann.me> 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?
Just to belabour this point unnecessarily :)
If you are familiar with the compiler innards, then this might be obvious.
However I am not, and I can imagine (crazy) scenario’s where an optional woud
be “unwrapped” by simply taking the reference to the self from the optional and
storing it in a new non-optional variable… :D … go figure… the mind works in
devious ways… lol.
Rien.
>
>> 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
