SE-0253: Callable values of user-defined nominal types

[Karl]

@beccadax

But func + itself stands out because the name is clearly special. It doesn’t need any additional marker to tell you something odd is going on. func call does not stand out in this way—it just looks like you’re declaring an ordinary method with the name call .

I don't agree that the magic behaviour of methods named + is obvious - as I showed, when you do that, you completely lose the ability to call it as a method (i.e. with MyType.+(lhs: ..., rhs: ...)), and the infix operator syntax is the only way to call it. That's not obvious behaviour. At least this proposal allows you to refer to the call method directly.

Also consider that this behaviour is not limited to +, but is the general behaviour for all operators. Including user-defined operators.

@John_Lin

Maybe core team treat it as a operator overloading case instead of adding capability of type?
If that's the case, how about

struct Adder {
    let base:Int
    func ()(i:Int) -> Int {
        return base+i
    }
}

this is a parser error in Swift 5. It matches how Swift & C++ works with operator overloading.

I agree - func () (...) is the name I would prefer. That was my initial suggestion last time, if you want to read the feedback.

I also agree with your review that Swift has a grab-bag of magic syntax features which has become difficult to reason about and teach. For that reason I think it's important that we keep dynamicCallable in mind when discussing this feature, and I basically see two possible ways forward:

• Either we model this feature on dynamicCallable, and take func call(...) to parallel func dynamicallyCall(args/kwArgs), or
• We remodel both on them on operators. func () (...) for static callable, and maybe some pseudo-operator like func (*) (args/kwArgs) for dynamic callable.

In any case, I think we can get rid of the type-level attribute. It's extra syntax, and an extra hurdle that I don't think we really need.