[swift-evolution] Variadic generics discussion

[Xiaodi Wu]

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:
>
>
> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160528/5153cb8a/attachment.html>