Can someone explain when and when not to use a 'weak' assignment to a delegate pointer in Swift, and why?
My understanding is that if you use a protocol that is not defined as a class you cannot, nor want to, assign your delegate pointer to weak.
protocol MyStructProtocol{
//whatever
}
struct MyStruct {
var delegate: MyStructProtocol?
}
However, when your protocol is defined as a class type protocol then you DO want to set your delegate to a weak pointer?
protocol MyClassProtocol:Class{
//whatever
}
class MyClass {
weak var delegate: MyClassProtocol?
}
Am I correct? In Apple's swift guide there class protocol examples aren't using weak assignments, but in my testing I'm seeing strong reference cycles if my delegates aren't weakly referenced.
You generally make class protocols (as defined with
class
keyword) weak to avoid the risk of a "strong reference cycle" (formerly known as a "retain cycle"). Failure to make the delegate weak doesn't mean that you inherently have a strong reference cycle, but merely that you could have one.With
struct
types, though, the strong reference cycle risk is greatly diminished becausestruct
types are not "reference" types, so it's harder to create strong reference cycle. But if the delegate object is a class object, then you might want to make the protocol a class protocol and make it weak.In my opinion, making class delegates weak is only partially to alleviate the risk of a strong reference cycle. It's really a question of "ownership". Most delegate protocols are situations where the object in question has no business claiming ownership over the delegate, but merely where the object in question is providing the ability to inform the delegate of something (or request something of it).
Delegates should (edit: generally) always be weak.
Lets say
b
is the delegate ofa
. Nowa
'sdelegate
property isb
.In a case where you want
b
to release whenc
is goneIf
c
holds a strong reference tob
andc
deallocates, you wantb
to deallocate withc
. However, using a strong delegate property ina
,b
will never get deallocated sincea
is holding on tob
strongly. Using a weak reference, as soon asb
loses the strong reference fromc
,b
will dealloc whenc
deallocs.Usually this is the intended behaviour, which is why you would want to use a
weak
property.