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.

Or Maybe Not So Simple?

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.

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.

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.

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.

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.

[1]

The X-Code playground is a very decent REPL for this kind of example. Here’s the code I used, if you want to play around on your own.

[2] I was amazed to find that Apple actually has a normal bug tracker for which I could create an account. Wonders never cease.↩

[3] I didn’t include the examples, but the type is unchanged with four, five and six sets of parentheses. The compiler treats them as semantically irrelevant, though the Swift grammar doesn’t allow for this, as far as I could tell from the BNF in the official manual.↩

[4] This is apparently legal in Swift, but I can’t divine its purpose in an actual program↩