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

[Dave Abrahams]

on Fri May 27 2016, Xiaodi Wu <swift-evolution at swift.org> wrote:

> Firstly, the syntax is about to get a lot cleaner. Soon, your example will be:
>
> func doSomething<
> S: Sequence, T: Sequence, U: Sequence
>>(foos: S, bars: T, bazzes: U)
> where S.Element == Foo, T.Element == Bar, U.Element == Baz
>
> Second, this syntax shows necessary complexity. Case in point: an array is a
> Collection with randomly accessible elements, yet in your example you chose
> SequenceType (aka Sequence). An instance of a type conforming to Sequence may or
> may not have randomly accessible elements, it may or may not be consumed after
> one pass, it may or may not have copy-on-write behavior, 

I know it's not really the point you're making, but “has copy-on-write
behavior” is not something we capture in a protocol constraint, and
it probably shouldn't be.

> and it may or may not be laid out contiguously in memory (which is not
> guaranteed for all arrays but is for arrays with elements of primitive
> type)--and that's if it's entirely held in memory at all.
>
> By writing out the function declaration the way it's shown above, it's clear
> what considerations that function will have to take into account. Assuming that
> it can operate on arbitrary sequences just like it can an array is a recipe for
> a lot of pain.
>
> On Fri, May 27, 2016 at 12:05 Charles Srstka via swift-evolution
> <swift-evolution at swift.org> wrote:
>
>         On May 27, 2016, at 9:31 AM, plx via swift-evolution
>         <swift-evolution at swift.org> wrote:
>
>         For the Sequence/Collection it’s a lot of work for IMHO a rather minor
>         convenience, but for more-complex type associated-type relationships it
>         could start to pay its own way.
>
>     Is it really that minor, though? For something so commonly encountered as
>     methods that take sequences/collections, this:
>
>     func doSomething(foos: [Foo], bars: [Bar], bazzes: [Baz])
>
>     is not only a whole lot easier to type, but is worlds clearer to read than:
>
>     func doSomething<S: SequenceType, T: SequenceType, U: SequenceType where
>     S.Generator.Element == Foo, T.Generator.Element == Bar, U.Generator.Element
>     == Baz>(foos: S, bars: T, bazzes: U)
>
>     Not only is the latter line intimidating to look at as is, but it separates
>     the contained type from the parameters themselves. Given how unwieldy this
>     second form is, it seems almost certain that the former line will be used
>     more frequently in the real world.
>
>     Charles
>
>     _______________________________________________
>     swift-evolution mailing list
>     swift-evolution at swift.org
>     https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave