[swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

Matthew Johnson matthew at anandabits.com
Tue May 24 17:55:25 CDT 2016

> On May 24, 2016, at 5:45 PM, Haravikk via swift-evolution <swift-evolution at swift.org> wrote:
>> On 24 May 2016, at 21:14, Leonardo Pessoa <me at lmpessoa.com <mailto:me at lmpessoa.com>> 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 <griotspeak at gmail.com <mailto:griotspeak at gmail.com>> 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 <austinzheng at gmail.com <mailto:austinzheng at gmail.com>> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160524/70ae0894/attachment.html>

More information about the swift-evolution mailing list