[swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)
dabrahams at apple.com
Thu Jan 28 01:19:32 CST 2016
on Wed Jan 27 2016, David Waite <swift-evolution at swift.org> wrote:
>> On Jan 27, 2016, at 1:56 PM, Howard Lovatt <howard.lovatt at gmail.com> wrote:
>> I would say that if it doesn't have arguments and doesn't mutate
>> then it should be a property, since it will read better and is
>> flexible (you can switch between a stored and calculated property
>> without affecting the external interface easily).
> It can mutate as long as the mutation is not externally visible on
> that interface. An example of this would be if the implementation of
> Set were internally backed by a Splay Tree, where balancing of the
> tree happens on every access.
> Another example is any computed property ever which output logging.
Well, if we wanted to spell all this out explicitly I'd say, “nothing
with side-effects that are both non-incidental (logging would be an
incidental side-effect) and visible to the caller may be a property.”
The guidelines group also takes these aspects for granted, because
although they are important, they are non-controversial. So the
document I posted doesn't mention them. We were trying to work on the
criteria for property-ness that were either ill-defined or caused more
More information about the swift-evolution