SE-0253: Static callables

[Karl]

@jrose

"Operator" means something specific in Swift today: a function with a specific name that takes either one value or two values as input at the call site with a particular spelling. Subscripts aren't "operators" in Swift even though they are in C++. I don't think operator () is particularly clear even in C++, since the parameters aren't even written inside the parantheses.

I don't support that narrow definition - for one thing, ternary operators exist and we even have one in Swift! We don't support user-defined ternary operators or allow custom implementations, but in theory there's no reason why we couldn't if there were some compelling use-cases.

but, I agree with the general argument: operators have a slightly different syntax at the point of use, but otherwise they are just ordinary functions. They are just sugar.

• When calling, I can write, say, 1 + 2 instead of Int.+(1, 2), and
• When referring to the operator's implementation (as in myInts.reduce(0, +)), I don't need to prefix the member name with a dot (myInts.reduce(0, .+))

And when you read this proposal, the same thing sticks out: myPoly(42) is just sugar around calling a specially-named function member: myPoly.evaluate(42) - or, spelled in more of an operator-y way: Polynomial.evaluate(myPoly, 42) (see my point above about how it's curious that we require operator implementations to be static).

So yes, static callables do not exactly fit within the very narrow range of stdlib-defined operators that we have today, but I think we only need to massage the edges a little bit, and that small expansion would be quite useful generally. The whole idea that there can be operators with an implementation-defined number of parameters with implementation-defined types and where argument labels are preserved is a powerful abstraction that could also help us solve problems like the unspellable requirements in the string-interpolation redesign.

P.S: As for subscripts: there is a reasonable argument that they also should be operators, but that would require an even larger expansion of the operator model.