SE-0216: User-defined dynamically callable types has been accepted.
Feedback on the proposal was almost entirely positive on both (1) the idea of supporting dynamically-typed calls and (2) the proposal's specific approach to providing that support. The major concerns expressed were:
-
Several community members felt that the feature was very complex, especially when combined with the future direction of dynamic member calls. Overall, though, the community seemed to feel that the feature was worth the complexity, and the core team agrees.
-
Many community members expressed concern that dynamically-typed member calls, which were originally pitched as part of this change, were demoted to a "future direction" in the actual proposal. This is seen as important for good interoperation with several major dynamic languages, including Ruby and JavaScript. The concern is that separating it from this proposal may substantially delay its introduction as a feature, and the core team agrees that that's the likely outcome: Swift probably won't support dynamically-typed member calls for awhile longer. However, they were removed from the proposal for a very good reason: implementing them is difficult in the current Swift type-checker, whereas implementing "freestanding" calls was straightforward. The core team values incremental progress in the language and doesn't feel that the absence of a related feature justifies holding up this one. There will be space for dynamically-typed member calls in the language when they're ready.
-
Relatedly, several people expressed concern that the design of dynamically-typed member calls might substantially affect the design of this feature, and so it is inappropriate to separate them. The core team feels that the design of dynamically-typed member calls has already been substantially completed, and it has only been delayed due to implementation difficulties. Furthermore, it is unlikely that the final design would want to unify the two dynamically-typed call features, as doing so would undermine a fairly important design goal already expressed in SE-0216: namely, the ability to statically reject structurally invalid calls (such as calls with argument labels in a language that doesn't support them).
-
There was also concern that Swift was adding support for a dynamically-typed call feature before it added support for a statically-typed call feature; this seems "un-Swifty". The core team feels that a statically-typed
@callablefeature might be interesting but is in practice a totally different feature with very different use cases and requiring a substantially different language design. -
Finally, several alternate language designs were explored in the review thread; the core team did not feel that any of them stood out as better than the proposal.
Therefore, the proposal was accepted without modifications. Thank you to everyone who participated in the review.