[swift-evolution] Variadic generics discussion
xiaodi.wu at gmail.com
Sat May 28 17:22:55 CDT 2016
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 <
swift-evolution at swift.org> 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:
> 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.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution