<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div id="AppleMailSignature">Something that long could probably use a "detailed design" section showing that some consideration was given to how to make it appear in a compiler. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><br></div><div>On May 28, 2016, at 10:03 PM, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Hello swift-evolution,<div><br></div><div>I put together a draft proposal for the variadic generics feature described in "Completing Generics" as a major objective for Swift 3.x. It can be found here:</div><div><br></div><div><a href="https://github.com/austinzheng/swift-evolution/blob/az-variadic-generics/proposals/XXXX-variadic-generics.md">https://github.com/austinzheng/swift-evolution/blob/az-variadic-generics/proposals/XXXX-variadic-generics.md</a><br></div><div><br></div><div>It adopts the syntax and semantics that are described in Completing Generics, and attempts to remain as simple as possible while still being useful for certain use cases (although I think there is still room to simplify). The proposal contains sample implementations for four use cases:</div><div><br></div><div>- Arbitrary-arity 'zip' sequence</div><div>- Arbitrary-arity tuple comparison for equality</div><div>- Tuple splat/function application</div><div>- Multiple-arity Clojure-style 'map' function</div><div><br></div><div>There is a lot of scope for design refinements, and even for alternative designs. With enhanced existentials, there was already an informal consensus that the feature would involve composing some protocols and class requirements, and placing constraints on the associated types, and most everything else was working out the various implications of doing so. That's not true for this feature.</div><div><br></div><div>In particular, I'm interested to see if there are similarly expressive designs that use exclusively tuple-based patterns and no parameter packs. I think Rust once considered a similar approach, although their proposal ended up introducing a parameter-pack like construct for use with fn application: <a href="https://github.com/rust-lang/rfcs/issues/376">https://github.com/rust-lang/rfcs/issues/376</a></div><div><br></div><div>Feedback would be greatly appreciated. Again, be unsparing.</div><div><br></div><div>Best,</div><div>Austin</div><div><br></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>