Hi all,

I’ve been working on implementing SE-0111: Remove type system significance of 
function argument labels 
<https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md>.
 Actually implementing this feature completely requires major surgery to the 
type system, ASTs, and so on. While 
<https://github.com/apple/swift/commit/847b78245a473cc7160e45289311c85b6d6365b5>
 I 
<https://github.com/apple/swift/commit/604adff1bdb9c6f515accd284156af4fe8153cde>
 am 
<https://github.com/apple/swift/commit/5cce5c4d1d6121cc812d63f74441a612c33f5226>
 making 
<https://github.com/apple/swift/commit/b40c89d4c6777bb69c3f7efe0e8ab8748c476994>
 progress 
<https://github.com/apple/swift/commit/e4d8f486a81021a2f66d8796dd3acaff3e02e4db>
 on this feature, it’s become clear that I cannot finish this in the Swift 3 
time frame.

On the other hand, this is a source-breaking change that we’ve accepted for 
Swift 3, and it’s one that is hard to implement for Swift 4 in a way that also 
allows us to implement the Swift 3 model in the same compiler. Rock, meet hard 
place.

So, I’m going to try a new implementation strategy, which (I think) will allow 
us to get the behavior of SE-0111 but without refactoring the whole world. 
Essentially, we need the argument labels to persist in the type system when 
we’re performing a call to a function. In all other cases, the argument labels 
should be stripped from the type. Note that we can determine *syntactically* 
whether a particular declaration reference is a direct callee, which means we 
can indicate when a particular reference should have argument labels (for call 
matching) or nor (for unapplied references to a function). For example, given:

        func f(a: Int, b: Int) -> Int { … }

        let f1 = f(a: 1, b: 1)    // treat ‘f’ as having type (a: Int, b: Int) 
-> Int, because we need argument labels for type checking
        let f2 = f                    // treat “f’ as having type (Int, Int) -> 
Int, because argument labels aren’t part of the type of ‘f’ (conceptually)
        let f3 = f(a:b:)(1, 2)   // treat ‘f’ as having type (Int, Int) -> Int, 
because references that include the argument labels don’t need further matching 
of the argument labels

References to instances methods on a metatype are a bit more interesting, 
because of the curried ’Self’, but can still be handled syntactically:

        struct X {
          func g(a: Int, b: Int) -> Int { … }
        }

        let x = X()
        let g1 = X.g                      // treat “X.g” as having type (X) -> 
(Int, Int) -> Int, because argument labels aren’t part of the type of ‘g’ 
(conceptually)
        let g2 = X.g(x)                  // treat “X.g” as having type (X) -> 
(Int, Int) -> Int, because argument labels aren’t part of the type of ‘g’ 
(conceptually)
        let g3 = X.g(x)(a: 1, b: 2)  // treat  “X.g” has having type (X) -> (a: 
Int, b: Int) -> Int, because the argument labels are needed to match up the 
arguments at the call site
        let g3 = X.g(a:b:)(x)(1, 2)  // treat  “X.g” has having type (X) -> 
(Int, Int) -> Int, because references that include the argument labels don’t 
need further matching of those argument labels

We can deal with this by, basically, computing the number of direct 
applications to a given declaration and recording that in the AST. Then we use 
that information when forming a reference to the given function declaration.

Along with this, we eliminate the ability to write a function type with 
argument labels in the type system, so we get the “var f: (_ a: Int, _ b: Int) 
-> Int” syntactic change as well.

        - Doug

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Reply via email to