Hello Swift community,
The review of SE-0253: Static callables ran from March 27... April 5, 2019. The core team is very positive about the idea of this feature, but would like to see some changes to the proposal, followed by another round of public review. As such, the proposal is returned for revision.
Much of the discussion revolved around a few related topics:
- How to spell a callable method: suggestions included things like
call(),func call(),call func(),func(),func _ (),func function(),@callable func evaluate() { - How to refer to a partially applied callable: The proposal started with the syntax of
value.callbut later removed it in order to simplify the proposal. - Whether or not the user should be able to specify a custom name for a callable definition.
- Whether or not there should be a type level attribute to indicate callability, and whether extensions should be marked callable.
The core team discussed all of these points at length. After discussion, the core team doesn't think that a type level attribute is necessary, and there is no reason to limit this to primal type declarations - it is fine to add callable members (or overloads) in extensions, just as you can add subscripts to a type in extensions today.
Similarly, the core team does not want to support user-defined unique names for callable declarations (e.g. allow call func myCallable(){}): this would complicate the internals of the compiler (including overload resolution) and thus the core team would like there to be a single (language defined) name.
On the first two points, the core team debated several designs and came to recommend that we keep callable syntax directly aligned with func to keep the function grammar consistent and make naming clear. In particular, the core team recommends picking a standard name (like call or invoke) that can be used as a normal named member, and which is automatically callable with function invocation syntax. This would give us syntax like func call(). With this approach, you can invoke the callable with with either value() or value.call(), and can partially apply the callable with value.call.
The core team discussed the fact that no matter what identifier is chosen, that this could impact some existing code that already uses that name. The core team doesn't find this concerning, because this only enables a new syntactic form that otherwise wasn't supported, so there should be no source compatibility problems. If the name is well chosen, no one should be surprised that it is callable.
The core team recommends that the proposal be revised to align with this approach, include a few alternatives for the name (including call, invoke, apply, and other ideas that may come up) and we will re-run the review for another cycle to see what the community thinks.
I want to thank the proposal authors and the community for all for the great feedback on this proposal review. Your comments, feedback, and thoughts directly contribute to making Swift a better language!
Thank you,
Chris Lattner
Review Manager