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

[Jonathan Tang]

On Sun, Jan 31, 2016 at 7:37 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution at swift.org> wrote:

> > There has to be an
> > underlying assumption that an Array's count must be a property, or
> > something else of that sort, in the background.
>
> You know, this would be a language change, but it occurs to me that, if a
> property could satisfy a protocol requirement for a parameterless method
> with no overloads, you *could* have an O(1) rule for properties.
> `Collection` would require a count() method, and `Array` would have a
> `count` property, and that would satisfy the requirement.
>
>
It seems like the unintended consequences of this could be really
confusing.  I think that most of us expect that replacing a concrete class
with a protocol that it conforms to will lead to the same semantics, at
least as long as we're only using the subset of functionality contained in
the protocol.  If properties and parameterless methods were
interchangeable, then you would have to refactor a lot of code from .count
to .count() when you changed an Array to a Collection.  And what happens if
'count' were, for the sake of argument, a function type?  Then .count() is
a perfectly legal expression that *calls* the property on an Array, but
*retrieves* the property on a Collection.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160201/c9e683e5/attachment.html>