Supporting Extensions for Structural Types

[Nevin]

@DevAndArtist

Any syntax for that feature is fine by me. I'm just worried about the postfix operator because it will read ambiguous in functions regardless of the ugliness of any these operators.

func foo(_: Int...) {} // variadic `Int` and only `Int`

struct R<T...> {
   func bar(_: T...) {} // Is it now a variadic list of only `T` or all T's?
}
struct S<...T> {
   func bar(_: ...T) {}
}

If there is no ambiguousness for the former form then I guess I can live with it, but it will require some mind-bending, because if you missed the parameter list from the type it's not clear what T... in the function really means until you check the original T .

In struct R<T...>, there is no single type “T”, so the func bar(_: T...) must take all the generic types “T...”. There is no meaning to “a variadic argument list of just type T”, because there is no type T.

I don’t know what (if any) syntax there will be for enumerating the individual types within T..., but if we use a strawman of indexing into T then you might be able to write, eg:

func bar(_: T[0]...)

(Which would presumably crash at runtime if T... is empty.)

@DevAndArtist

Consider these two types where the operators have different meanings.

struct A<...T> {}
let a: A<Int, String, Bool> = ...

struct B<T...> {}
let b: B<Int, Int, Int> = ...
let invalid_b: B<Int, String> = ... // error `T` must be of the same type.

Requiring that multiple generic parameters be the same is…not really desirable. Your struct B only has one generic parameter, so it should not use variadic generics at all. If it needs a generic multiplicity parameter as well, then I recommend heading over to the Generics Vector Manifesto thread.