SE-0253: Static callables

[dan-zheng]

@Jon_Hull

As I said above, I don't actually think .call solves this problem for any of the syntax choices, because:

• It overloads .call (what if you have func call() ?)
• You have to know the magic name
• It is special, but it feels like a normal member reference
• It can't disambiguate between different call signatures
• It breaks the metaphor of the type itself being the callable thing for the caller

I'm not quite convinced of these problems.
What is a use case where a type would define both func call and a call member?

I also wonder when/how often it's necessary to disambiguate overloaded call members via explicit casting. I don't particularly see a reason to store let x = foo.call in an intermediate variable. When applying foo(...) directly, overload resolution based on arguments' types should be sufficient (unless result types are overloaded).

---

@Jon_Hull

It just says: "treat this type like this particular function signature", and that is totally in line with the meaning of a callable. I really think anyone (fluent in Swift) coming across it in code will be able to grok the meaning without having to look anything up. Compare that to .call which most people will assume at first glance is a member reference.

I do generally agree with this sentiment of uniformly treating callables like functions.

Is your idea to support explicit casting to function types via as, and to not support implicit conversion? If I understood you correctly, that is an interesting direction and avoids implicit conversion complications.

---

@michelf

Personally, I don't feel the need for this. I'm quite happy making closure and passing around function types. I'm not too fond of the idea of "values representing functions" that aren't function types. I like to have clear lines between some concepts instead of "everything can act like anything".

I find it makes little sense to be able to "call" a Parser , or "call" a Model , or "call" a Polynomial .

Thanks for your perspective! I think @allevato made some great points in the pitch thread that are relevant to your response:

@allevato

I will grant that the facta that Swift has context-capturing first-class functions means that many of the uses of operator() from early C++ (until lambdas were introduced) can be duplicated that way instead, but there's still value in being able to treat state and application as a single unit . Today in Swift, you only have three options:

• You pass the state and call an explicit function, losing the notational benefits that you want

• You pass the state's member function, losing the ability to query or mutate the state itself because it's captured by the function and inaccessible otherwise

• You pass both, obfuscating the API

A call operation resolves this nicely for the problem domains that benefit from it.

Context-capturing functions and closures are great for certain use cases. But mutable state and application are often encapsulated as nominal types with instance methods. Call-syntax sugar for instance methods representing "function application" is valuable.

---

@michelf

I find it makes little sense to be able to "call" a Parser , or "call" a Model , or "call" a Polynomial . The goal of these examples seems entirely about saving some typing at the call site, but you can already bind the function you want to a variable:

let eval = Polynomial(coefficients: [2, 3, 4]).evaluated

print(eval(2)) // => 24

Instead of using the verb "call", I would think in terms of "application": applying a parser, machine learning model, or polynomial function. Application (of the primary, function-like behavior) of these constructs does make sense.

---

@michelf

I'm a bit puzzled about how this interacts (or not) with SE-0111 which removed the type system significance of function argument labels in function types. It was hinted at the time that variables of a function type would eventually get "compound names", allowing the labels to become part of the variable's name.

This proposal simply presents a syntactic sugar: foo(x: 1, 2, 3) is rewritten as an instance member application foo.call(x: 1, 2, 3). Such sugars are not related to the type system significance of function argument labels.