[swift-evolution] Ownership on protocol property requirements

Greg Spiers gspiers at gmail.com
Sun May 7 06:54:21 CDT 2017


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](

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](
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.


Greg Spiers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170507/40436b2d/attachment.html>

More information about the swift-evolution mailing list