AFAIK a new kind of decl (like the original proposal) is out of scope.
Otherwise, I'd prefer we introduced an operator func modifier, more like C++: it clearly indicates that those members are not usable like regular member functions, even without type-level attributes, it can be used to avoid collisions and provide better diagnostics and auto-complete, and it scales to future features.
struct Foo {
operator func call(...) { /* ... */ }
operator func memberLookup(...) { /*...*/ }
}
And it could be used for our other operators, like + and +=:
struct Foo {
operator func + (other: Foo) -> Foo { /* ... */ }
mutating operator func += (other: Foo) { /* ... */ }
}
By the way, how much nicer is it to write += as a mutating instance member like that? As opposed to what we have now:
struct Foo {
static func += (lhs: inout Foo, rhs: Foo) { /* ... */ }
}
The only niggle is that you couldn't refer to the function for things like partial application. It's nice that the core team considers that important, but you can't even refer to more basic operators like + for those things today!
let f = Int.+= // Error
let f: (inout Int, Int) = += // Error
A general solution to that would be welcome. Perhaps something like #operator(Foo.call) or #operator(infix, Int.+). That would allow us to disambiguate between the operator "call" and a non-operator function which was coincidentally named "call".
This is what I meant in the original review when I said we should be looking at these features like operators. init/deinit are not just like normal functions; there are certain things you must do in an init, and the compiler checks that you do them, there are chaining rules, etc.
is the true way of the Function Call, I shall leave you all with an imaginary quote from the fake movie The Motrix: "Do you hear that, Mr. Bikeshed? That's the sound of deadlines whooshing over your head."
