Variadic Generics

[Karl]

@mklbtz

Maybe, in "code", documentation, warnings, etc. it would be appear as any Whatever , but in implementation it's not actually a sequence existential values. After all, the compiler would be optimizing away all that loop-like code since it knows the number of elements statically.

Right - it couldn't be an opaque type, because opaque types are, well, opaque "non-names" for a single underlying type.

But I do think there is significant overlap between existentials (and especially collections of existentials) and variadic generics, and the language is currently not well-equipped to deal with either of them comfortably because we don't have a concept of introducing new generic type parameters in the middle of a function. That's why, in the previous thread, I suggested that adding this would be a good step towards variadic generics:

Pitching The Start of Variadic Generics

One thing that might be useful as a step towards variadic generics is introducing local generic parameters. For example, as @xAlien95 pointed out: func debugPrint<T...>(_ items: T...) where T: CustomDebugStringConvertible { for (item: T) in items { // <--- Here stdout.write(item.debugDescription) } } The T on the marked line is actually a new, local generic parameter which overrides the name T... in the function declaration. Actually, the T on that line refers to a different typ…

So I think it would be reasonable for the element type to be an existential, which the optimiser could then resolve during generic specialisation.

Also, I don't think it's true that the compiler always statically knows the number of elements. You can have unspecialised generic types today, and presumably variadic generic types may also be unspecialised in some circumstances.