[swift-evolution] Variadic generics discussion

[Austin Zheng]

I appreciate your feedback! Some thoughts inline...

> On May 28, 2016, at 3:22 PM, 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?

I can't see any real reason to not change it if it's confusing and/or ugly. I stole the syntax from the generics manifesto for use as a starting point.

The only real reason would be if there would be some sort of syntactic ambiguity from using just one of the two. But I can't think of any - a type or value gets the leading dots iff it would be a declaration anyways.

We could even go further and only require any dots on the type parameters. Value packs would look the same as normal values (although they wouldn't be interchangeable), and the only way to tell would be to see that they were declared with a parameter pack as their type or constructed from another value pack. But that might be even more confusing to people reading the code.

> * 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?

I gave this a bit of thought last night but didn't come up with anything compelling:

- Maybe something using "#": "func bar<T#.., U, V>", since '#' cannot start custom operators?
- A #pack(T) construct or other pseudo-function? "func bar<#pack(T), U, V>"
- Maybe an underscore followed by dots? "func bar<T_.., U, V>", but "_" already plays a role signifying something meant to be ignored or discarded
- Maybe we keep the three dots, but only use them with the generic type parameters (no naming conflict possible there). So you can declare a pack using T..., but you never use the three-dot syntax with a value pack.
- Carve out an exception in the grammar and require postfix dot operators to have four or more dots?

> * It's a little bit unfortunate that #unpack() takes a triple and gives you a pack. Shouldn't it be #pack()?

That's a good point. What I had in mind was "unpacking" a scalar tuple's values into a value pack. But then we have an #unpack() operator that turns something into a "pack", which is absurd. It should be renamed, or we could change the terminology from "packs" to "vectors" (e.g. "parameter vector", "value vector") or something. Unpacking the members of a scalar into a "value vector" sounds a lot better.


> On Sat, May 28, 2016 at 16:03 Austin Zheng via swift-evolution <swift-evolution at swift.org <mailto: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 <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 <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 <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/1eb951e4/attachment.html>