[swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)

[Dave Abrahams]

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.
>
> https://en.wikipedia.org/wiki/Splay_tree
>
> 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
disagreement.

-- 
-Dave