Initial Semantics for Variadic Generics

[CodaFi]

Implements a variation of the semantics described in the initial pitch.

This patchset implements

• Variadic type argument binding with structural saturation rules
• AST for parameter packs, pack expansions, and their corresponding types
• Type inference rules for variadic generic applies
• Substitution rules for polyvariadic types with eager pack expansions
• A pack-expansion-to-tuple conversion

Notably missing:

• Syntax for null-bound variadic generic types e.g. Foo<> for Foo<T...>
• Semantics for null-bound variadic generic functions func foo<T...>(_ xs: T...); foo()
• Pack arity propagation along type equality constraints

---

The heart of this patchset is an inference scheme for variadic generic functions and associated pack expansions.

A traditional variadic function looks like

func foo<T>(_ xs: T...) {}

Along with the corresponding function type

<T>(T [variadic]) -> Void

which the constraint system only has to resolve one type for. Hence it opens <T> as a type variable and uses each argument to the function to try to solve for <T>. This approach cannot work for variadic generics as each argument would try to bind to the same <T> and the constraint system would lose coherency in the one case we need it: when the arguments all have different types.

Instead, notice when we encounter expansion types:

func print<T...>(_ xs: T...)
print("Macs say Hello in", 42, "different languages")

We open this type as

print : ($t0...) -> ($t0...)

Now for the brand new stuff: We need to create and bind a pack to $t0, which will trigger the expansion we need for CSApply to see a coherent view of the world. This means we need to examine the argument list and construct the pack type <$t1, $t2, $t3, ...> - one type variable per argument - and bind it to $t0. There's also the catch that each argument that references the opened type $t0 needs to have the same parallel structure, including its arity. The algorithm is thus:

For input type F : (... ($t0...), ..., ($tn..) ...) -> R and an apply site F(a0, ..., an) we walk the parameters of F and record an entry in a mapping for each opened variadic generic parameter. Now, for each argument ai in (a0, ..., an), we create a fresh type variable corresponding to the argument ai, and record an additional entry in the parameter pack type elements corresponding to that argument.

Concretely, suppose we have

func print2<T..., U...>(first: T..., second: U...) {}
print2(first: "", 42, (), second: [42])

We open print2 as

print2 : ($t0..., $t1...) -> Void

And construct a mapping

  $t0 => <$t2, $t3, $t4> // eventually <String, Int, Void>
  $t1 => <$t5> // eventually [Int]

We then yield the entries of this map back to the solver, which constructs bind constraints where each => occurs in the diagram above. The pack type thus is immediately substituted into the corresponding pack expansion type which produces a fully-expanded pack type of the correct arity that the solver can actually use to make forward progress.

Applying the solution is as simple as pulling out the pack type and coercing arguments element-wise into a pack expression.

You would think this would appear in the literature somewhere, but lo and behold I'm pretty sure nobody's thought to do this yet.

[CodaFi]

@swift-ci test

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 72d5678ac041e4437b3deff727042e7b4e2f2917

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 72d5678ac041e4437b3deff727042e7b4e2f2917

[CodaFi]

@swift-ci test

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - d44d8ec

[CodaFi]

@swift-ci test macOS platform

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - d44d8ec

[CodaFi]

@swift-ci smoke test macOS