Published by Marco on 4. Feb 2017 21:45:15
------------------------------------------------------------------------

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.

[A Simple, Generic Function]

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

[image]

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.

[image]

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.

[image]

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. [2] 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.

[image]

  * 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:

[image]

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 [3]
  * (1) => Tuple
  * ((1)) => Tuple>
  * ...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.

[image]

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.
  
   func test(_ 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)))


[1] 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.


[1] This is apparently legal in Swift, but I can't divine its purpose in an
    actual program