<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 28, 2016, at 3:03 PM, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hello swift-evolution,<div class=""><br class=""></div><div class="">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></div></blockquote><div><br class=""></div><div>Austin, this is really exciting! Thank you very much for all of the work you’re doing on “Completing Generics”. These features are at the very top of my list of desired features in Swift.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class=""><a href="https://github.com/austinzheng/swift-evolution/blob/az-variadic-generics/proposals/XXXX-variadic-generics.md" class="">https://github.com/austinzheng/swift-evolution/blob/az-variadic-generics/proposals/XXXX-variadic-generics.md</a><br class=""></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">- Arbitrary-arity 'zip' sequence</div><div class="">- Arbitrary-arity tuple comparison for equality</div><div class="">- Tuple splat/function application</div><div class="">- Multiple-arity Clojure-style 'map’ function</div></div></div></blockquote><div><br class=""></div><div>These are some very good and clearly articulated examples. Great work! This section is important because variadics are somewhat complicated and it is important to show people why we want them and what problems they can solve.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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" class="">https://github.com/rust-lang/rfcs/issues/376</a></div></div></div></blockquote><div><br class=""></div><div>As far as I can tell, the way you are approaching `apply` would not allow the default arguments of the function passed as `function` to be used when calling `apply`. Arguments would have to be provided for all parameters when the function is invoked through apply.</div><div><br class=""></div><div>I know that this difficulty is not directly related to variadic generics, but it does demonstrate a limitation of this approach to forwarding.</div><div><br class=""></div><div>I have already run into a use case where I would like to accept a function and a pack of arguments, store the arguments, be able to compare them for equality, and later invoke the function with them. However, in order for this approach to make sense in my use case it would be essential that the user *not* need to explicitly provide arguments for parameters with defaults.</div><div><br class=""></div><div>I bring this up in hopes that we might try to explore designs that would support this use case, and at least give it some consideration. I’m trying to think of ways to make this work but haven’t come up with anything obvious yet.</div><div><br class=""></div><div>-Matthew</div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Feedback would be greatly appreciated. Again, be unsparing.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Austin</div><div class=""><br class=""></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>