What is your evaluation of the proposal?
My evaluation of the proposal is very positive. I feel that implementing the @dynamicCallable attribute is the natuaral next step after implementing the @dynamicMemberLookup attribute in 0195 to provide support for dynamic languages.
I also like the proposed ambiguity solution for types that contain withArguments: and withKeywordArgument methods. This was a question that came up in my mind while reading through the proposed solution.
Is the problem being addressed significant enough to warrant a change to Swift?
I believe it is. Since the @dynamicMemberLookup attribute was added to Swift, accessing a property of a Python instance is relatively straight forward. However, calling a method on that instance is a lot more cumbersome. For example:
Python:
class compute:
def __init__(self, text):
self.data = text
def get_data(self):
return self.data
Swift:
let computeModule = Python.import("Compute.compute")
// The cumbersome call method to create the computedInstance
let computedInstance: PyVal = computeModule.get(member: "compute").call(args: "Swift Data")
// Accessing a property on that Python instance
print(computedInstance.data)
Does this proposal fit well with the feel and direction of Swift?
In my opinion, yes. I feel Swift is starting to gain ground on the server and also in popular machine learning libraries so providing support for Swift to interop with dynamic languages to me only makes sense.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
N/A
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I did an in-depth study of the proposal on Github as well as putting together live code samples to at least test out @dynamicMemberLookup. I am also a Python fan, so putting together the code samples was fun!