The syntax for variadic generics

[hborla (Holly Borla)]

@Slava_Pestov

1. Declaring a type pack in a generic parameter list, <T...>
2. Expanding a type pack T in a type context, like a function parameter type: args: Array<T>...
3. Expanding a value pack x in expression context, like an argument to a call: forward(args: foo(x)...)

However I suspect that at least 2 and 3 should use the same syntax to avoid confusion, especially since types can appear in expression context, like Array<T>.self... to form a value pack of metatypes by expanding a type pack T.

I agree; I think it's important for pack expansion to be expressed in the same way at the type and value level.

@xwu

As we've discussed in the past I've been a fan of the postfix * operator due to its parallels with the regex syntax we now support in the language, where * also means zero or more of something exactly as it does for a pack. (On a cursory review, it seems Scala uses postfix * for variadic arguments, so there's some other precedent for that, and many of us are no doubt familiar with Python's prefix * syntax.)

The point about the operator's subtlety is well taken; I think if we want a little more verbosity, using a "wordy" pack declaration syntax seems to work nicely.

Using a keyword for pack declarations also might help indicate that * means something different than a pointer type in Swift for those familiar with other languages where * means pointers. That said, the pack declaration keyword wouldn't always be directly visible, e.g. if you're in an extension over a variadic generic type:

struct Container<pack Value> { ... }

// in another file
extension Container {
  func getTuple() -> (Value*) { ... }
}

@ebg

I don't know if this is possible, but can we automatically bridge non-pack variadic parameters into packs, and use ...?

The problem isn't non-pack variadic parameters using .... The issue is that ... is used as a postfix and infix range operator, and attempting to migrate this family of operators would be a big undertaking that comes with a large source break:

@hborla

Unfortunately it's not just about the postfix range operator .... The partial range operator intentionally uses the same operator as the regular closed range infix operator 1 ... x.count. Then there's also the closely related half-open range operator 1 ..< x.count that intentionally matches the structure of the closed-range operator, just with a different final character to denote the open/closed property of the range. While it might be feasible to change all of these operators to be spelled differently, these are such widely used operators that I don't think it would be worth the tradeoff.

If we're concerned about the existing uses of ... in Swift, I think we should instead consider using a different syntax for variadic generics.