Re: [swift-users] weak self

[Guillaume Lessard via swift-users]

> On May 2, 2017, at 00:05, Rien  wrote:
> 
> 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?

I also don’t think there’s a symmetry break there. A weak reference is 
effectively a shared variable between threads, so its value can change between 
any two actions. This would be the same if it were an Optional that happens to 
be shared between threads, but you’d have to handle locking yourself. An `if 
let` binding to a strong reference is effectively a lightweight lock against 
deletion of your object.

The more critical thing is that if you need to perform more than one action 
with a weak reference, you really should bind it to a strong reference first. 
The optional chaining approach is a fine shortcut for a single action.

Cheers,
Guillaume Lessard

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] weak self

[Chris McIntyre via swift-users]

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  
> 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  
>> wrote:
>> 
>> Hi Rien,
>> 
>>> On May 1, 2017, at 08:46, Rien via swift-users  
>>> 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 
>> .
>>  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

Re: [swift-users] weak self

[Rien via swift-users]

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  
> wrote:
> 
> Hi Rien,
> 
>> On May 1, 2017, at 08:46, Rien via swift-users  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 
> .
>  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

Re: [swift-users] weak self

[Zhao Xin via swift-users]

 [weak self] and [unowned self] are used to solve the problem of Strong
Reference Cycles Between Class Instances

.

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  wrote:
>
>
> On 01 May 2017, at 16:59, Dennis Weissmann 
> wrote:
>
>
> On May 1, 2017, at 4:46 PM, Rien via swift-users 
> 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

Re: [swift-users] weak self

[Rien via swift-users]

> On 01 May 2017, at 17:42, Dennis Weissmann  wrote:
> 
>> 
>> On May 1, 2017, at 5:32 PM, Rien  wrote:
>> 
>>> 
>>> On 01 May 2017, at 16:59, Dennis Weissmann  
>>> wrote:
>>> 
 
 On May 1, 2017, at 4:46 PM, Rien via swift-users  
 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

Re: [swift-users] weak self

[Dennis Weissmann via swift-users]

> On May 1, 2017, at 5:32 PM, Rien  wrote:
> 
>> 
>> On 01 May 2017, at 16:59, Dennis Weissmann  wrote:
>> 
>>> 
>>> On May 1, 2017, at 4:46 PM, Rien via swift-users  
>>> 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

Re: [swift-users] weak self

[Rien via swift-users]

> On 01 May 2017, at 16:59, Dennis Weissmann  wrote:
> 
>> 
>> On May 1, 2017, at 4:46 PM, Rien via swift-users  
>> 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’. 
;-)

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

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] weak self

[Dennis Weissmann via swift-users]

> On May 1, 2017, at 4:46 PM, Rien via swift-users  
> 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.

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

Re: [swift-users] weak self

[Adrian Zubarev via swift-users]

Not answering the questions, but sharing a neat trick.

[weak self] in

guard let `self` = self else { return }

self.foo() // strong self :)


-- 
Adrian Zubarev
Sent with Airmail

Am 1. Mai 2017 um 16:46:33, Rien via swift-users (swift-users@swift.org) 
schrieb:

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

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

[swift-users] weak self

[Rien via swift-users]

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

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