Firstly, the syntax is about to get a lot cleaner. Soon, your example will be:<br><br>func doSomething&lt;<br>  S: Sequence, T: Sequence, U: Sequence<br>&gt;(foos: S, bars: T, bazzes: U)<br>where S.Element == Foo, T.Element == Bar, U.Element == Baz<br><br>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&#39;s if it&#39;s entirely held in memory at all.<br><br>By writing out the function declaration the way it&#39;s shown above, it&#39;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.<br><br><div class="gmail_quote"><div dir="ltr">On Fri, May 27, 2016 at 12:05 Charles Srstka via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><blockquote type="cite">On May 27, 2016, at 9:31 AM, plx via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br></blockquote><div><blockquote type="cite"><br><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">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.</span></div></blockquote></div><br></div><div style="word-wrap:break-word"><div>Is it really that minor, though? For something so commonly encountered as methods that take sequences/collections, this:</div><div><br></div><div>func doSomething(foos: [Foo], bars: [Bar], bazzes: [Baz])</div><div><br></div><div>is not only a whole lot easier to type, but is worlds clearer to read than:</div><div><br></div><div>func doSomething&lt;S: SequenceType, T: SequenceType, U: SequenceType where S.Generator.Element == Foo, T.Generator.Element == Bar, U.Generator.Element == Baz&gt;(foos: S, bars: T, bazzes: U)</div><div><br></div><div>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.</div></div><div style="word-wrap:break-word"><div><br></div><div>Charles</div><div><br></div></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>