Hello,
I hope this is the appropriate place to raise this discussion and see if
it's worth a proposal around which direction to take.
I've recently had some confusion around specifying weak for a property in a
protocol and surprised later of not being warned if the adopting type does
not also specify weak for the property. There is an open bug around this
behaviour [SR-479](https://bugs.swift.org/browse/SR-479\). Example:
class A {}
protocol P {
weak var weakVar: A? { get set }
}
class B: P {
var weakVar: A? // Not declared weak, no compiler warning/error
}
Jordan Rose left the comment, "We need to figure out what weak means in a
protocol. We should probably ban it for now."
It is a little inconsistent to allow an ownership attribute in a protocol
but not enforce the same attribute in the adopting type I think. I guess
the point could be made that it's to document/hint that the type adopting
the protocol should use the ownership attribute suggested? The Swift
Programming Language reference has this to say about Property Requirements
in Protocols:
“A protocol can require any conforming type to provide an instance property
or type property with a particular name and type. The protocol doesn’t
specify whether the property should be a stored property or a computed
property—it only specifies the required property name and type.”
There’s no mention if the protocol can specify weak/unowned for a property.
My concern is that this is a warning when this situation happens in
Objective-C and there's another bug that makes this point [SR-1494](
https://bugs.swift.org/browse/SR-1494\).
Would that be desirable behaviour to warn/error in Swift in the adopting
type? Or does it make more sense as Jordan commented on the original bug to
ban it in protocols (technically a source breaking change)?
I've done some initial investigation on how difficult it would be to
[implement banning it in protocols](
https://github.com/gspiers/swift/commit/ecde3ec5f61f259f8a396618e9973bac04536fd0\).
This would be my first contribution so sorry the code will need some work
but I'm happy to try and get it in shape and work on a proposal if people
think it's worth fixing.
Thanks,
Greg Spiers