<div dir="ltr">Sorry. That sentence should read: [Foo] is an array. Collection<Foo> means nothing in Swift right now, but it really does look awfully like a generic protocol by analogy.<div><br></div><div>Since I'm here, I might as well keep on digging...</div><div><br></div><div>Right now, we have good syntax delineation. Generic types and functions are immediately obvious because of the characteristic angle brackets placed after the function or type name (with the exception of the three big sugared generic types in the stdlib - Array, Dictionary, and Optional). We also have protocol<...> to build an existential out of one or more protocols, although there has been some discussion in other threads about whether people might confuse that syntax with generic type syntax and whether it should be changed as a result. Associated types don't use the angle brackets, but they aren't really generic types - they can be used to constrain generic types, but they also show up in places like defining constrained protocol extensions, whose methods don't necessarily need to be used in a generic function.</div><div><br></div><div>I think the fact that it's reasonably easy to tell these three loosely defined families of type features apart is a valuable aspect of the language's design, and loosening this ability should be done very carefully.</div><div><br></div><div>Austin</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 24, 2016 at 7:19 PM, Austin Zheng <span dir="ltr"><<a href="mailto:austinzheng@gmail.com" target="_blank">austinzheng@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I regret mentioning existentials; I am aware that an existential that isn't sufficiently constrained will never be able to provide the same guarantees as a generic type variable. My argument is that even a partially constrained existential is useful if there is a useful set of APIs that don't touch the associated types in question. I do not believe that they fulfill the same role as generics, and I apologize for writing a response that strongly implied they were.</div><div><br></div><div>That being said, my opinion regarding this suggestion is still this: [Foo] is not an array, Collection<Foo> is not a generic protocol, and I am strongly against any sort of compiler magic that makes those types mean anything other than what they appear to be.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Austin</div></font></span><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
If this rule:<br>
<span><br>
> The generalized existentials proposal goes out of its way to be explicit about the fact that only type safe operations would be visible through the existential.<br>
<br>
</span>Is trying to say that this isn't the case because APIs using the collection's `Index` are not exposed on an `AnyCollection`, well, then I'm not sure what `AnyCollection` is actually supposed to be used for.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span><font color="#888888"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
</font></span></blockquote></span></div><br></div></div>
</blockquote></div><br></div>