> 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?
I guess „dynamic“ isn’t a common property name, but imho such magic doesn’t 
feel right, even when there are no collisions in real-world code.

>       let y =  np^.arange?^(24)?^.reshape^?(2, 3, 4)!

That looks quite ugly… but imho that’s at least partially because of the choice 
of character
let y = np:arange?:reshape?:(2, 3, 4)!
doesn’t seem to be as bad as the use of carets.

But still, you would have to jump through some hoops to use both kinds of 
dispatch side by side (because you always have to think about how to call a 
On the other hand, we also have &inoutParameter and try, which makes some 
things less convenient — and I’d say that dynamic dispatch is somehow 
comparable to inout-parameters (both shouldn’t be used if you can get around 

So, why do people want differentiate?
I can see two major motivations for a different syntax:

a) you want to dynamic calls to stand out — which also could be done by tools:
> let y =  np.arange?(24)?.reshape?(2, 3, 4)! // let the editor use a different 
> font/color for non-static stuff

b) you want to be sure that in a given situation, no dynamic dispatch is used — 
which could be solved by keeping the dot as general way to call something, and 
add an alternative that will only use static lookup

No matter what direction is taken here, imho this whole story has a really 
gigantic impact on the shape of Swift, and I have strong concerns if the two 
changes are reviewed in a normal way and added this year… there’s no experience 
with the proposed changes yet, and afaics, it has become quite hard to correct 
additions that turn out to be not as positive as expected.

- Tino

swift-evolution mailing list

Reply via email to