> 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 method). 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 it). 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 swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
