The second review of SE-0253 - Callable values of user-defined nominal types ran through May 13. Compared to the first round, the feedback was relatively light, mostly focused on the options of how to spell the callable member, more discussions of a
@callable attribute, many ways to spell the call method, as well as the higher level purpose of this extension.
The core team discussed the various options, whether an attribute was important, the tradeoffs between various names. For example, the
invoke is sort of a term of art in
NSInvocation but SE-0216 / @dynamicCallable has standardized the terminology of "call" already in the Swift community. There are existing
func call implementations (e.g. there could be a
Phone.call() method), and subtly providing callable behavior with a short and common name like
call could be seen as surprising. The core team felt that the attribute doesn't appear to pay for itself, and existing types don't need to have an attribute to be subscript-able.
After discussing these and many other points, the core team decided to accept the proposal, with the request to change
func call() syntax to
func callFunction() . The core team chose this direction because it retains the 'call' nomenclature established by SE-0216, but is a more verbose name that is less likely to already exist, or be accidentally used for an unrelated purpose.
Accordingly, SE-0251 is accepted with modification .
As part of this discussion, the Core Team also considered the behavior of the existing dynamic call (SE-0216) and dynamic member-lookup (SE-0195) features. These features both require an attribute on the original type declaration, preventing retroactive extension of a type to support these features. In both cases, the attribute was not included in the original proposal, but was added during the review out of concern for abuse. The Core Team has not asked for a similar attribute for static calls because it has changed its mind and no longer agrees with this concern; it does not align with Swift's general design principles to restrict features this way. We therefore invite a new proposal to remove these restrictions.