What is your evaluation of the proposal?
+1. I’m really happy to see this proposal move forward. It has been really well thought, and it has gone through many reviews to endup being in this final form, which I really like. Adding this powers to the language and having access to other ecosystems will be great for Swift.
Furthermore I really like that it gives to user level code some language level powers, and with minimal impact in the compiler. As a Swift user I really care about the burden that the compiler has to take with each new feature as it affects my day to day directly (we all want a good performant error-free compiler), so adding this powerful feature with minimal invasion seems like a good deal.
Is the problem being addressed significant enough to warrant a change to Swift?
I think so. This proposal won’t only allow current Swift developers like us to use a new bast number of libraries but, and for me much more important, will facilitate people from other communities to start peeking into the Swift ecosystem. Would make it easier for them to start writing Swift if they know they can still use their favourite libraries.
Does this proposal fit well with the feel and direction of Swift?
This makes the language much more powerful, which will help with world domination.
And what I really like is that it still does it in a way that allows dynamic layers to be written in a type safe manner by returning Optional for example. It doesn’t throw out the door the nice and safer things about Swift.
That said, and is not rare coming from me, I still would love to see in the future really powerful metaprogramming facilities that would allow user level code to implement something like type providers to give progressive typing to APIs implemented with this Dynamic protocols.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I haven’t used anything similar in a strongly static typed language. But this is similar to Objective-C forwarding selector mechanism, and it’s obviously how Ruby works all the time.
The point with that feature of Objective-C is that 99% of the time in all my experience we just use the typed APIs, but is nice to have a tool that allows you to do runtime magic when necessary.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I’ve been interested in this proposal since Chris suggested it with a first post in the mailing list. I participated in the conversation during all this time, I read all the versions of the proposal and tried the different versions of the Python playground.
I want to thank Chris for taking the time to evolve the proposal properly, accepting and acting on the feedback and not rushing it. Even when the initial feedback was pretty negative. Thanks!
That said, I have a couple of questions that won’t affect my review but I’m still curious to know the answer for:
- The proposal mentions proxies. One think I would really like is to have a class that proxies method calls to an injected value. But thinking how to do it with this proposal the only way I can think of is to have a big if/else checking for the function name and then forward them manually with “static” (like written in the source) calls to the underlaying object. Is there any piece I’m missing that would allow this to work without the big if/else?
- Given that the protocol doesn’t have formal requirements, what would happen if the subscript has multiple overloads? Would the actual Swift resolution machinery just kick in?