Hi Chris,

I am definitely in favor of providing dynamic features in Swift, and of being 
able to interoperate easily with dynamic languages. I really like the idea 

I was about to write up a different idea I had for partially mitigating some of 
the issues around being able to mistype method names, etc…, but then I 
remembered a usability principle that I first heard from members of the Lisa 
team (discovered the hard way): Things which behave the same should look the 
same, and things which behave differently need to look different.

I like that the change in behavior is really limited in scope by this proposal, 
but there still isn’t really any indication other than the type (which might be 
inferred) that the normal checking behavior is offline.  When in a fully 
dynamic environment, this isn’t really a big problem because you use different 
debugging strategies,  but I worry that the free mixture of static and dynamic 
without any indicators showing the difference will lead to much more frequent 

What do you think about having a special method ‘dynamic' defined in this 
protocol, such that the compiler magic lookup behavior is only available when 
chained after that method?  Thus:


would have to be:


Now, I know that sounds like a pain in the butt, but it also buys you an extra 
ability (in addition to the extra cue that we have to watch out for dynamic 
issues).  Because the dynamic lookup only happens for calls chained after 
dynamic, we now have normal swift lookup for all of the other 
methods/properties defined on the type (with autocomplete support, etc…).

What this means is that it is easy to wrap commonly used calls in a normal 
swift method:

        func addTrick(_ name:String) {

Now the user can say the following with full autocomplete support, type 
checking, etc…


…and if they misspell it, they will get an error from the compiler.  Error 
handling could also optionally be added to a wrapper.  Most importantly, 
conversion to/from swift return types and parameters can easily be built into 
the wrappers.

The end result is a system where python code can be up and running in Swift 
very quickly (by using chaining with .dynamic), and then made more native Swift 
friendly incrementally over time (by adding wrappers/extensions for 
common/important calls).  The only extra cost is having to type an extra word 
for dynamic calls without wrappers.



swift-evolution mailing list

Reply via email to