First off, it'd probably be best to wait to have this discussion until
the RFC is available, so that we can be sure we're all commenting on
the same thing. The current design evolved after many hours of
discussion about the precise performance requirements we wanted to
meet as well as exploring the design space that we saw (yes, this
includes the HasPrefix proposal). I'm not inclined to dive into the
full details of our thought process just yet; I'd rather include that
as part of the RFC or else as a blog post, because it's a very
complicated issue.

I personally think that offering some kind of virtual structs fits
completely within Rust. We've always tried to avoid "one size fits
all" thinking -- in real life there are performance tradeoffs, and you
often can't cover the entire space with a single design. This is why
we offer multiple pointer types, closures vs procs, and so forth.

I agree that the existing trait objects are the better approach in
most regards. They are extensible, so you can add new interfaces
later. They provide a convenient choice between static and dynamic
dispatch. In general, I hope that Rust programmers will reach for
traits first.

However, the extensibility of trait objects comes at the cost of fat
pointers, which can be a problem if you have a lot of pointers. It
also implies that downcasting isn't really possible, at least not
cheaply, because there is no notion of the "actual type" of a
particular object. The whole notion of downcasting rests on the idea
that there is a single dynamic type of the object that we can
test. (Downcasting can be emulated with virtual method dispatch, at
the cost of boilerplate and efficiency; but this is one of those
details I'd prefer to leave for a blog post or RFC.)

(As an aside, I am personally happier to see virtual structs than to
see traits extending structs or traits extending a `HasPrefix` trait,
as was included in previous designs. Both of those approaches mean
that the trait is no longer "pure interface", and if you write
"generic" code against that trait, you're actually coding at least
partially against a fixed implementation, not an interface.)

In summary, I believe that only providing trait objects is a kind of
"one size fits all" thinking.  In specialized cases, where single
inheritance is sufficient and extensibility is not desired, we can
offer other abstractions that perform better.



regards,

Niko
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to