Can we forbid weak keyword for computed properties?


(Jordan Rose) #21

There's something to be said for presentation of an interface being part of defining a library, even if it's unenforceable. But I agree with Michel otherwise: if we take this away, we shouldn't print it at all, or else we've made going from stored to computed property observable in the generated interface.


#22

I'm shifting my position a little bit based on the feedback in this thread.

In the case of (say) a "delegate" property, it is of course vital to know whether the object takes ownership or not. It's typical (in Apple frameworks) that it's zeroing weak, but some are not, so it's important to "mark" the exceptions.

In the case of a stored property in Swift (and a synthesized @property in ObjC), it's a very natural alignment for weak to be both a storage annotation and an API contract.

In the case of a computed property in Swift (and an ObjC @property with a custom implementation), there is a great possibility of error if the weak annotation is "only" an API contract, and not something that the compiler somehow enforces or validates.

This is not a theoretical problem in ObjC, but an actual source of memory management bugs.

So, keeping weak on computed properties works as API documentation, but easily becomes a source of bugs. Outlawing it is safer, but forces the documentation to be separate from the API.

Both seem viable, but opinion seems to be split on which is better.


(Michel Fortin) #23

Inside the setter of a weak computed property, could we issue a warning on assigning newValue to a non-weak stored property of self? That'd make the annotation useful, even though it'd be easy to evade.