<div style="white-space:pre-wrap">Erm, autocorrect deserves credit for converting 'tuple' to 'triple.' Sorry.<br></div><br><div class="gmail_quote"><div dir="ltr">On Sat, May 28, 2016 at 18:22 Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Some initial thoughts, from a guy who doesn't remember his C++ very well:<br><br>* The motivation for using prefix ... at declaration and postfix ... elsewhere seems lacking in this proposal; is this necessary in Swift? If so, why? If not, can we stick with one or the other?<br>* There's going to be some Swift-specific funniness since ... is an existing infix operator; currently, it's possible to define custom ... prefix and postfix operators. Is there an intuitive syntax that avoids this re-appropriating of an existing facility?<br>* It's a little bit unfortunate that #unpack() takes a triple and gives you a pack. Shouldn't it be #pack()?<br><div class="gmail_quote"><div dir="ltr">On Sat, May 28, 2016 at 16:03 Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank">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" target="_blank">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>
_______________________________________________<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></blockquote></div>