<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">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">&gt; There has to be an<br>
&gt; underlying assumption that an Array&#39;s count must be a property, or<br>
&gt; 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&#39;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 &#39;count&#39; 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>