[swift-evolution] [Pitch] Changing NSObject dispatch behavior

[Brian King]

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.

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 `commonly_proposed.md`, 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.

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.

Brian

On Thu, Dec 15, 2016 at 10:00 PM, Joe Groff <jgroff at apple.com> wrote:

>
> > On Dec 15, 2016, at 6:48 PM, Brian King <brianaking at gmail.com> wrote:
> >
> > 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.
>
> 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.
>
> -Joe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161215/710db8fa/attachment.html>