As I said before in the other contemporaneous thread, the feature does exactly what it says on the tin: it’s callable as a function, not implicitly convertible to a function.
1 Like
I agree that it does what it says. But as to the rest, my question still stands. Why not?
It looks like a duck, walks like a duck, quacks like a duck... but I can't pass it off as a duck. 
Especially in a language that purports to treat functions as first class citizens.
1 Like
The answer is that the arguments for doing so don’t meet the very high bar for adding another ad-hoc implicit conversion to the language.
Indeed, as I recall, a major use case for callAsFunction and a number of other features added around that time was first-class support for bridging to dynamic languages that hasn’t really panned out, so if any change were to be made in this area going forward, it’d be to remove callAsFunction altogether.
1 Like
Don't say things like that. The callAsFunction method is extremely useful in builder patterns, and I use it in the Factory DI system to easily indicate that you want a factories value to resolve.
6 Likes
personally i teach it as the sole available mechanism for constructing a nominal function type. removing that would be catastrophic for me
3 Likes
I personally think that's not true. callAsFunction is a fundamental building block of JavaScriptKit, and removing it not would only break this library (and potentially many others), but also make bridging to JavaScript much harder to implement.
I'm not sure what you mean by "hasn't really panned out", as callAsFunction and other related features, at least with JavaScript bridging, did enable a whole field of new applications targeting the browser. I don't have enough experience with PythonKit to say how crucial it is to the autodiff/ML ecosystem, but I wouldn't surprised if it takes a similar important niche in that space.
5 Likes