SE-0216 @dynamicCallable implementation blockers

[dan-zheng]

Hi Mark, thanks for the reply! Sorry for the late response. I have a specific question for you in bold, near the bottom of this post.

@rudkx

However the example you gave with:

let _: Float = s("hi")
// Should resolve to `s.dynamicallyCall(withKeywordArguments: ["": "hi"]

obviously conflicts with that idea, so I'm wondering you really intended to say that this is the overload that it would resolve to?

The example here is an advanced case, and with this amendment we don't have to handle it. I would like to solve the simple case first, which is illustrated in your example below and in my first example.

@rudkx

What I think you want to end up generating for the constraint system for an example like this:

@dynamicallyCallable
struct Callable {
  func dynamicallyCall(withArguments: [Int]) {}
  func dynamicallyCall(withKeywordArguments: [String : Int]) {}
}

let c = Callable()
c(1, 2, 3)

is a single ApplicableFunction constraint with a single argument of type Array<$T1> that resolves to the withArguments overload of dynamicallyCall .

This is the "simple" case. I do generate the constraints you described, actually. In the example I shared above, $T4 binds to the withArguments method overloads, $T5 is the type of the single argument conforming to ExpressibleByArrayLiteral, and a ($T5) -> $T3 applicable fn $T4 constraint is generated.

The problem is the crash in matchCallArguments above. I believe normally, each type variable corresponds to an expression in the AST, so the "shape" of the ApplicableFn constraint matches the shape of the expression/type variables (e.g. foo(1, [2, 3]) produces ($T4, $T5) -> $T6 applicable fn $T1).

However, dynamic calls break this precedent. The type variables in the CallExpr look like ($T4, $T5, ..., $Tn) -> $Result but the constraint always looks like ($ExpressibleByArrayLiteral) -> $Result. I think this is the reason for the matchCallArguments crash.

I'm not sure about how to best fix this crash: my best idea now to add a new "DynamicCallableApplicableFn" constraint kind whose simplification logic looks similar to ApplicableFn except it calls a modified version of matchCallArguments. This seems like it'll lead to a lot of code dupe though - please let me know if this approach is acceptable or if you have other ideas.

@rudkx

In Swift we can have a property and method with the same name:

...

I think this could end up being really problematic to deal with, so you may need to explicitly disallow it (meaning having a property of a @dynamicallyCallable type with the same name as a method) to get this proposal implemented.

Thank you for pointing out this tricky case. Explicitly disallowing it for now makes sense, I'll certainly add a test case like the example you provided to exercise that logic.