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

[Xiaodi Wu]

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, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160527/72f0becb/attachment.html>