Some initial thoughts, from a guy who doesn't remember his C++ very well: * 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? * 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? * It's a little bit unfortunate that #unpack() takes a triple and gives you a pack. Shouldn't it be #pack()? On Sat, May 28, 2016 at 16:03 Austin Zheng via swift-evolution < [email protected]> wrote:
> Hello swift-evolution, > > 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: > > > https://github.com/austinzheng/swift-evolution/blob/az-variadic-generics/proposals/XXXX-variadic-generics.md > > 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: > > - Arbitrary-arity 'zip' sequence > - Arbitrary-arity tuple comparison for equality > - Tuple splat/function application > - Multiple-arity Clojure-style 'map' function > > 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. > > 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: https://github.com/rust-lang/rfcs/issues/376 > > Feedback would be greatly appreciated. Again, be unsparing. > > Best, > Austin > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
