<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><div><br><br>Sent from my iPad</div><div><br>On May 29, 2016, at 7:36 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><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div class="">I significantly rewrote the proposal to take into account as much feedback as I could. (Many things, like syntax, haven't been changed yet, but will be in a forthcoming version.)</div><div class=""><br class=""></div><div class="">What I did change:</div><div class=""><br class=""></div><div class="">- Renamed 'packs' to 'vectors'</div></div></blockquote><div><br></div><div>What is the rationale here? Vector makes some sense for the parameter packs because they only consist of types and are thus homogenous. But value packs and argument packs will consist of values or arguments that might all have different types. They are heterogeneous. So vector doesn't seem like the right term. It's not a huge deal, but something to consider anyway.</div><div><br></div><div>By the way, the multiMap example is basically the same as the applicative functor for ZipList in Haskell (<a href="http://learnyouahaskell.com/functors-applicative-functors-and-monoids#applicative-functors">http://learnyouahaskell.com/functors-applicative-functors-and-monoids#applicative-functors</a>). You can probably find several more good examples by looking at other applicative functors.</div><div><br></div><div>Still thinking about more robust function forwarding but not making much progress...</div><br><blockquote type="cite"><div><div class="">- Discussed variadic typealiases a bit, including things like "variadic String" for holding the results of vector computations</div><div class="">- There's a "every variadic associated type must be equal" constraint that can be defined now</div><div class="">- I added a section discussing a "fold" operation, to reduce a value pack/value vector into a single scalar with the help of a user-defined function.</div><div class="">- I changed the proposal so that making a tuple out of a vector now requires surrounding the vector with #tuple(), to get rid of the 'implicit' rules that plx brought up</div><div class="">- I added a section briefly discussing how this feature might be implemented.</div><div class=""><br class=""></div><div class="">Some thoughts:</div><div class=""><br class=""></div><div class="">- Things like indexing into a value vector by an integer value would be extremely powerful. But as far as I can tell they'd require a great deal of macro-like functionality to go along with them. A way to define constant expressions would be required, so we could define "#index = #count(T...)" or something. Then we'd need ways to manipulate that value (increment or decrement) if we wanted to work with the previous or next elements in a chain, we'd need compile-time conditional checking so that a variadic generic could behave correctly for the first or last item in a vector, and so forth. Omitting these expensive features is going to limit the number of uses variadic generics have; is this tradeoff going to be worth it? Could we push off those features to a later date, if/when Swift gets an actual compile time metaprogramming design?</div><div class=""><br class=""></div><div class="">- The more I think about things, the more I'm leaning towards the idea that tuples are the only construct necessary. We could get rid of most of the features of value packs/vectors, and allow them to only serve two roles: defining a variadic generic function, and spreading out a tuple in order to call a variadic generic function. (I think I prefer a spreading operator to bringing back the magic compiler tuple splat functionality.) They could also be "spread out" to define or specialize a different variadic generic type. Thoughts?</div><div class=""><br class=""></div><div class="">- With the existence of 'fold', might it be worth it to remove #tail() (and maybe #head), at least from v1? This would represent a slight loss of expressive power for common use cases in exchange for a considerable decrease in complexity.</div><div class=""><br class=""></div><div class="">Alternatively, some tuple-based designs might make this point obsolete. Imagine something like this:</div><div class=""><br class=""></div><div class="">func head<T, ...U>(input: (T, U...)) -> T { ... }</div><div class="">func tail<T, ...U>(input: (T, U...)) -> (U...) { ... }</div><div class=""><br class=""></div><div class="">Again, any comments are welcome. I hope to continue evolving this proposal as the community decides what they want and don't want to see.</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On May 28, 2016, at 1:03 PM, Austin Zheng <<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</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 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 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 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>
</div></blockquote></div><br class=""></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></div></body></html>