I would love to know if anyone is strongly opposed to the staticallyCall syntax. I think callFunction is clearly opposed by some people so I think staticallyCall at least could be a better compromise agreement.
The core team discussed staticallyCall and other variants that incorporated the word "static". The problem is that this can exist as protocol requirements and on classes, which are dynamically dispatched (through existentials and subclasses). We'd prefer to avoid the opportunity for confusion if possible.
Joe has some ideas (I don't know if they are baked or not) and would like to see the existing dynamic callable feature get revised (beyond removing the attribute and restrictions) to do something like kwargs in Python. This could lead to the existing entrypoint getting renamed, so I wouldn't over index on the dynamicallyCall entrypoint naming.
If you are referring to my post I used "awkward" in the sense of alien to Swift syntax and inconsistent with other API, not in the "awkward to read" sense.
What about callValue? Since the function defines a way to call a value directly, that seems pretty clear and concise to me. It can leave things open to allowing types to be called directly too with a different function name, if in the future a different name is desired for that.
Ok, that's interesting. So, adding kwargs to Swift would mean that dynamicallyCall and staticallyCall could be centralized in a unique magic function-name.
I would like to better understand the rationale for rejecting anonymous / unnamed methods. Is it primarily that you feel very strongly about being able to name the entity directly?
Given the insistence on a compound, currently valid identifier, how about performCall or performFunctionCall? Those read substantially better to me than callFunction which feels quite awkward and is easy to interpret in ways that donât align with what the method actually does. The potential for confusion with callFunction is especially prevalent if the signature accepts a single argument of function type.
The syntax func callFunction is delightfully redundant.
What sets apart this particular function from every other function--which, as noted by others, are all callable--isn't that it's a function. Rather, it's that it enables a callable value.
I wouldnât see that as a conflict, but every regular function name could be used by someone who doesnât want a callable type (that could mean that this ability is just ignored, though).
âGooglabilityâ however is imho only a strong argument when itâs about marketing - and in the context of this feature, I hardly see any benefit at all:
People might search for â@someAttribute funcâ, or âmethod without a nameâ when they encounter it. On the other hand, âfunc callFunctionâ is not even a trigger for research - itâs just a method with an odd name and no indication that there is something special about it.
Probably mentioned before, but what about having global functions of the form call(_:) whose first argument is the type to call, and that can be quasi-overloaded with various types and parameters?
For example:
struct Filter {}
// Note: These are global functions, not instance/static methods
func call(_ filter: Filter) {} // No arguments
func call(_ filter: Filter, alpha: Double) // Additional parameters
let filter = Filter()
filter()
filter(alpha: 0.5)
If you want to reference the function, thatâs easy enough, plus you can disambiguate between overloads by providing argument labels:
func call(filter: Filter, alpha: Double) {}
let function = call(filter:alpha:)
Why do I think this is worth considering?
Supports both types and metatypes
Follows API guidelines. âcall objectâ -> call(_ object: Object)
Far less likely to collide than a call member function (in my unscientific opinion)
Still allows for referencing the function directly/passing as parameter
Doesnât require new keyword or anything. Essentially same as proposed solution but just global function
Since it doesnât require any additional language features, itâs (hopefully) just as simple to implement. Only thing I can think of is maybe that would be too difficult for the compiler with all the overloads?