on Fri May 27 2016, Xiaodi Wu <swift-evolution@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@swift.org> wrote: > > On May 27, 2016, at 9:31 AM, plx via swift-evolution > <swift-evolution@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution -- Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution