A tuple-inference bug in the Swift 3.0.1 compiler

I encountered some curious behavior while writing a service-locator interface (_protocol_) in Swift. I’ve reproduced the issue in a stripped-down playground[1] and am almost certain I’ve found a bug in the Swift 3.0.1 compiler included in XCode 8.2.1.

Update: At the suggestion of a reader, I searched and found Apple’s Jira for Swift[2] and reported this issue as A possible tuple-inference/parameter-resolution bug in Swift 3.0.1

A Simple, Generic Function

We’ll start off with a very basic example, shown below.

Simple argument with label

The example above shows a very simple function, generic in its single parameter with a required argument label a:. As expected, the compiler determines the generic type T to be Int.

I’m not a big fan of argument labels for such simple functions, so I like to use the _ to free the caller from writing the label, as shown below.

Simple argument without label

As you can see, the result of calling the function is unchanged.

Or Maybe Not So Simple?

Let’s try calling the function with some other combinations of parameters and see what happens.

Label-less argument with tuples and multiple parameters

If you’re coming from another programming language, it might be quite surprising that the Swift compiler happily compiles every single one of these examples. Let’s take them one at a time.

• int: This works as expected
• odd: This is the call that I experienced in my original code. At the time, I was utterly mystified how Swift—a supposedly very strictly typed language—allowed me to call a function with a single parameter with two parameters. This example’s output makes it more obvious what’s going on here: Swift interpreted the two parameters as a Tuple. Is that correct, though? Are the parentheses allowed to serve double-duty both as part of the function-call expression and as part of the tuple expression?
• tuple: With two sets of parentheses, it’s clear that the compiler interprets T as tuple (Int, Int).
• labels: The issue with double-duty parentheses isn’t limited to anonymous tuples. The compiler treats what looks like two labeled function-call parameters as a tuple with two Ints labeled a: and b:.
• nestedTuple: The compiler seems to be playing fast and loose with parentheses inside of a function call. The compiler sees the same type for the parameter with one, two and three sets of parentheses.[3] I would have expected the type to be ((Int, Int)) instead.
• complexTuple: As with tuple, the compiler interprets the type for this call correctly.

Narrowing Down the Issue

The issue with double-duty parentheses seems to be limited to function calls without argument labels. When I changed the function definition to require a label, the compiler choked on all of the calls, as expected. To fix the problem, I added the argument label for each call and you can see the results below.

Labeled argument with tuples and multiple parameters

• int: This works as expected
• odd: With an argument label, instead of inferring the tuple type (Int, Int), the compiler correctly binds the label to the first parameter 1. The second parameter 2 is marked as an error.
• tuple: With two sets of parentheses, it’s clear that the compiler interprets T as tuple (Int, Int).
• labels: This example behaves the same as odd, with the second parameter b: 2 flagged as an error.
• nestedTuple: This example works the same as tuple, with the compiler ignoring the extra set of parentheses, as it did without an argument label.
• complexTuple: As with tuple, the compiler interprets the type for this call correctly.

Swift Grammar

I claimed above that I was pretty sure that we’re looking at a compiler bug here. I took a closer look at the productions for tuples and functions defined in The Swift Programming Language (Swift 3.0.1) manual available from Apple.

First, let’s look at tuples:

Grammar of a Tuple Expression

As expected, a tuple expression is created by surrounding zero or more comma-separated expressions (with optional identifiers) in parentheses. I don’t see anything about folding parentheses in the grammar, so it’s unclear why (((1))) produces the same type as (1). Using parentheses makes it a bit difficult to see what’s going on with the types, so I’m going to translate to C# notation.

• () => empty tuple[4]
• (1) => Tuple<int>
• ((1)) => Tuple<Tuple<int>>
• …and so on.

This seems to be a separate issue from the second, but opposite, problem: instead of ignoring parentheses, the compiler allows one set of parentheses to simultaneously denote the argument clause of a single-arity function call and an argument of type Tuple encompassing all parameters.

A look at the grammar of a function call shows that the parentheses are required.

Grammar of a Function Call Expression

Nowhere did I find anything in the grammar that would allow the kind of folding I observed in the compiler, as shown in the examples above. I’m honestly not sure how that would be indicated in grammar notation.

Conclusion

Given how surprising the result is, I can’t imagine this is anything but a bug. Even if it can be shown that the Swift compiler is correctly interpreting these cases, it’s confusing that the type-inference is different with and without labels.

func test<T>(_ a: T) -> String
{
  return String(describing: type(of: T.self))
}

var int = test(1)
var odd = test(1, 2)
var tuple = test((1, 2))
var labels = test(a: 1, b: 2)
var nestedTuple = test(((1, 2)))
var complexTuple = test((1, (2, 3)))