<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On 24 May 2016, at 21:14, Leonardo Pessoa &lt;<a href="mailto:me@lmpessoa.com" class="">me@lmpessoa.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class="">My first question here would be "what's the gain?" I understand<br class="">CollectionTypes and arrays may be something different but I myself<br class="">admit I don't know and wonder how that change would be a benefit to<br class="">us?</div></blockquote><br class=""></div><div>Instead of functions only accepting an Array, which is a specific type, they would accept any collection type, including all the lazy collections.</div><div><br class=""></div><div><div><blockquote type="cite" class=""><div class="">On 24 May 2016, at 21:16, T.J. Usiyan &lt;<a href="mailto:griotspeak@gmail.com" class="">griotspeak@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">I agree that Sequence or Collection is what is more often 'meant' but what you propose is an awkward to explain/defend betrayal, in my opinion.</div></div></div></blockquote><br class=""></div><div>I’m not sure I’d call it a “betrayal”, there aren’t many methods on Array that aren’t covered by CollectionType, and those that are aren’t available as an immutable type anyway (which all function parameters are now), so to do anything array-specific requires extra steps that a fix-it might be able to cover if CollectionType is too general for your method.</div><div><br class=""></div><div>The problem is that when there’s a shorthand, people tend to use it, but the problem is that most of the time any collection or sequence type will do, and that an array isn’t actually required at all. After seeing a bunch of examples of [Foo] before I knew about how to handle generics properly I found it a tricky habit to break. Could be more of a failing in the way Swift is being taught right now perhaps, but then generics can’t really be taught any sooner either, it’s tricky.</div><div><br class=""></div><div>It may be too much of a breaking change I’ll grant, but at the same time it seems better to shake this up and get people using the correct method for passing/receiving collections by default.</div></div></div><br class=""><div><blockquote type="cite" class=""><div class="">On 24 May 2016, at 21:15, Austin Zheng &lt;<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Better support for existentials (see the generics manifesto,&nbsp;<a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md" class="">https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md</a>) should obviate the need for any sort of sugar or compiler magic to do this kind of thing.<div class=""><br class=""></div><div class="">typealias AnyCollection&lt;T&gt; = Any&lt;Collection where .Element == T, ...&gt;</div><div class="">func doSomething(collection: AnyCollection&lt;Foo&gt;)</div></div></div></blockquote><br class=""></div><div>Hmm, that does look like it could cover it, thanks for linking this! Just to double check, but Any is a new root for all types then, so this isn’t the same as a type-erased wrapper?</div></body></html>