[swift-evolution] Variadic generics discussion

[Xiaodi Wu]

Erm, autocorrect deserves credit for converting 'tuple' to 'triple.' Sorry.

On Sat, May 28, 2016 at 18:22 Xiaodi Wu <xiaodi.wu at gmail.com> 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 <
> 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/6da0c332/attachment.html>