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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
