<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Jan 31, 2016 at 7:37 PM, Brent Royal-Gordon via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> There has to be an<br>
> underlying assumption that an Array's count must be a property, or<br>
> something else of that sort, in the background.<br>
<br>
</span>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.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>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.</div></div></div></div>