Erm, autocorrect deserves credit for converting 'tuple' to 'triple.' Sorry.
On Sat, May 28, 2016 at 18:22 Xiaodi Wu <[email protected]> wrote: > 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
