I'm not enamoured by the design direction but grateful that the opportunity to bikeshed callFunction was offered as that name is just aesthetically terrible. func functionCall(...) is nicer although the repetition of 'func' right after is a little awkward. func callAsFunction(...) is grammatically sound, descriptive, and looks decent.
(Minor win: there's also less chance that callAsFunction will clash with user code simply because it is longer and not a 'noun'; functionCall is perhaps in the realm of DSL territory.)
The weird about this whole thing IMO is that we're trying to name a thing and then never use said thing's name. This is why I prefer the _ since in Swift it signals the omission of a name. All other names look like somewhat poorly named functions to me and they don't make their special behaviour clear because I can still invoke them like obj.performCall() for instance. _ would not really let me do that (or should obj._() work? IDK)
Like many others here, I would prefer not to have a magical function name that looks just like everything else but results in special behavior. My order of preference from what has been mentioned:
A new call keyword (similar to subscript or init)
func _ or a completely unnamed func
func callSelf
I don't like callFunction or callAsFunction since that's what happens with all functions anyways...callSelfAsFunction would be more technically correct but that is far too long for my liking.
Since I doubt 1 or 2 would be accepted by the core team I would much prefer callSelf over the alternatives suggested.
This is essentially what I wanted to say as well. I've reached the limited of magical behavior in Swift: a strangely named function that enables niche functionality through nothing more than its name.
We want an ordinary function name, and we want a āgoodā one, but we want to avoid one that could conflict with existing names.
If the name didnāt need to be that of an ordinary function (i.e., if it could be a special keyword call as originally proposed, like init) then thereās no possible conflict, and the task would be straightforward.
If the name didnāt need to avoid conflicts, then we could pick func call as in the revised proposal.
The core team now wants to find a compound name. One major problem with this is: Suppose we choose the name frobnicateCall. If I type frobnicateCall, then I opt into a powerful new feature. If I type forbnicateCall, then there is nothing that can help me find the error. If there were a protocol or attribute I could opt into, then the diagnostics would tell me Iām missing a requirement. If it were a special keyword, then the parser would complain. If it were spelled callāwell, how many ways can you misspell call?
All of this is to say that, if weāre going to make certain ordinary members have particular significance without protocol conformances, attributes, or keywords, then it ought to stand out in some way to avoid conflicts or unintentional use and also be difficult to misspell.
So Iāll put forward a simple suggestion: copy Python and name this __call or __call__.
__call or __call__ has been my preferred alternative. __ is a good candidate in my mind for, "hey this is something special, you should learn what this is." I'd probably also redesign @dynamicCallable to __dynamicCall__.
I think that looks incredible ugly and is actually one reason why I donāt like Python...
My feelings about a single underscore are similar, and I really donāt think that is a good fit either:
There are situations where we need āsomething thatās nothingā, but that is not the case here, as func () is not ambiguous.
After all, we donāt want to write unnamed tuples like (_: Int, _: Int), do we?
That's part of the reason _ is used in these type of method definitions. They aren't meant to be called or used directly, which is what static callable is all about anyway. So there's no reason for it to look read/look like a normal method, it's just a known hook into a type to expose/support some functionality. Which is something normally done via protocols. But you can dig into the background of the dynamicMemberLookup and callable proposals to see why real protocols don't work well for these kinds of features.
Yes, __call__ at least would be clearly special/magical and easy to know what it does (search it on Google and you already can find what it does on Python). Also we would create a new Swift convention: all magic names should be marked with a double underscore prefix and suffix.