On Jun 25, 2016, at 12:49 , William Squires <[email protected]> wrote: > > I was looking at the problem from the caller's end (i.e. client code), not > the callee's end, so the semantic requirements (such as getters not being > able to modify instance variables) aren't a consideration here.
It does, subtly, affect the caller’s end, too. The fact that it’s a property rather than a function allows the compiler to apply different optimizations (because it knows that the value is immutable, for example), not to mention giving a reader of the code a hint that there are no side effects from examining the property value, at least not on the value itself. I should also have mentioned earlier that if the property and function are @objc, then as a matter of implementation they’re identical, but the compiler still won’t let you confuse them in Swift code. I’d expect an error message if you tried to put both in the same class, because you’d essentially have duplicate names. _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
