<div dir="ltr"><div>OK, this is great, a little detail just clicked that I had not fully thought through. My suggestion of using message dispatch only for NSObject isn't really possible since `dynamic` doesn't support Swift types yet. So any form of consistency argument is out the window.<br></div><div><br></div><div>But what is clear from the general tone is that dynamic behavior is to be opted into, and that's not changing. I can PR `<a href="http://commonly_proposed.md">commonly_proposed.md</a>`, to save future runtime happy developers from treading into these waters if interested. I am interested in ways to make dynamic easier to use, but I'm not sure flagging a declaration is helpful enough to warrant the syntax.</div><div><br></div><div>Thanks all, I have a blog post to update, and I'm going to get back to playing around with SR-584 -- the bug that began it all.</div><div><br>Brian</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 15, 2016 at 10:00 PM, Joe Groff <span dir="ltr"><<a href="mailto:jgroff@apple.com" target="_blank">jgroff@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_-3397677789582883696gmail-"><br>
> On Dec 15, 2016, at 6:48 PM, Brian King <<a href="mailto:brianaking@gmail.com" target="_blank">brianaking@gmail.com</a>> wrote:<br>
><br>
> Thanks Joe, that makes a lot of sense. But is the only metric for "the best possible strategy" performance? The best possible metric for NSObject could be to use message dispatch, because consistency with the frameworks and with it's legacy.<br>
<br>
</span>The performance cost of objc_msgSend isn't that high, but it only supports dispatching ObjC-compatible methods. We'll need something similar to objc_msgSend for Swift method dispatch in its full generality, but vtables are easier to implement (and do have a much lower startup and dirty memory cost, and slightly lower per-method-call cost, so there are good reasons to use vtables when possible). The dispatch mechanism is orthogonal to the language semantics, and is an implementation detail. We don't want methods to be arbitrarily overridable at runtime by default, for reasons Kevin articulated well, and when the method implementation is bound at compile time, it shouldn't really matter how it's dispatched.<br>
<span class="gmail-m_-3397677789582883696gmail-HOEnZb"><font color="#888888"><br>
-Joe<br>
</font></span></blockquote></div><br></div></div>