<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 24, 2016, at 5:45 PM, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On 24 May 2016, at 21:14, Leonardo Pessoa <<a href="mailto:me@lmpessoa.com" class="">me@lmpessoa.com</a>> 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 class="">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 class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On 24 May 2016, at 21:16, T.J. Usiyan <<a href="mailto:griotspeak@gmail.com" class="">griotspeak@gmail.com</a>> 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 class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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></div></div></blockquote><div><br class=""></div><div>The idea of shorthand for commonly used generics and / or existentials is interesting. I’m not sure stealing the array syntax which is both familiar and similar to other languages is the right approach but it is worth considering. </div><div><br class=""></div><div>If we do go down this path I think an important part of the discussion is whether the shorthand introduces an implicit generic parameter, whether it uses an existential, or whether the user has control over this. Joe Groff has mentioned that he would like these to have the same behavior eventually, but that is not the case today. I’m not sure what is involved in making the behavior the same or what the timeframe for that might look like.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 24 May 2016, at 21:15, Austin Zheng <<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Better support for existentials (see the generics manifesto, <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<T> = Any<Collection where .Element == T, ...></div><div class="">func doSomething(collection: AnyCollection<Foo>)</div></div></div></blockquote><br class=""></div><div class="">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></div></div></blockquote><div><br class=""></div><div>Yes, generalized existentials are roughly equivalent to type-erased wrappers except you don’t have to write them manually.</div><br class=""><blockquote type="cite" class=""><div class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>