> On May 24, 2016, at 5:45 PM, Haravikk via swift-evolution > <[email protected]> wrote: > > >> On 24 May 2016, at 21:14, Leonardo Pessoa <[email protected] >> <mailto:[email protected]>> wrote: >> >> My first question here would be "what's the gain?" I understand >> CollectionTypes and arrays may be something different but I myself >> admit I don't know and wonder how that change would be a benefit to >> us? > > Instead of functions only accepting an Array, which is a specific type, they > would accept any collection type, including all the lazy collections. > >> On 24 May 2016, at 21:16, T.J. Usiyan <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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. > > 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. > > 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. > > 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.
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. 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. > >> On 24 May 2016, at 21:15, Austin Zheng <[email protected] >> <mailto:[email protected]>> wrote: >> >> Better support for existentials (see the generics manifesto, >> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md >> <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md>) >> should obviate the need for any sort of sugar or compiler magic to do this >> kind of thing. >> >> typealias AnyCollection<T> = Any<Collection where .Element == T, ...> >> func doSomething(collection: AnyCollection<Foo>) > > 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? Yes, generalized existentials are roughly equivalent to type-erased wrappers except you don’t have to write them manually. > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
