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.
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.
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.
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 expectedodd
: 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 interpretsT
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 labeleda:
andb:
.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 withtuple
, 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.
int
: This works as expectedodd
: With an argument label, instead of inferring the tuple type(Int, Int)
, the compiler correctly binds the label to the first parameter1
. The second parameter2
is marked as an error.tuple
: With two sets of parentheses, it’s clear that the compiler interpretsT
as tuple(Int, Int)
.labels
: This example behaves the same asodd
, with the second parameterb: 2
flagged as an error.nestedTuple
: This example works the same astuple
, with the compiler ignoring the extra set of parentheses, as it did without an argument label.complexTuple
: As withtuple
, 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:
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.
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.
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.
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)))
↩