[rust-dev] Traits and @ boxes in stdlib/rustc

Huon Wilson dbau.pp at gmail.com
Mon Apr 22 05:54:13 PDT 2013

Hi all,

I've got a few questions:

There are many instances of functions returning and taking dynamic
trait objects in @ boxes (e.g. all of the io functions, things dealing
with core::rand::Rng, core::run::Program) rather than a plain type
(for return values) or a generic (for arguments), this seems a little
peculiar given it (probably?) has a runtime cost due to the vtables
and the extra GC required. Is this legacy code that hasn't been
updated yet? And, is there a reason for it remain in the dynamic
objects form? (I know there's no point touching the io stuff since it
is all being redone.)

To give an example, I'm talking about converting items like (all
from core::rand)

     fn Rng() -> @Rng
     fn rand(rng: @rand::Rng) -> Self
     impl RngUtil for @Rng


     fn Rng() -> RandRes
     fn rand<R: rand::Rng>(rng: &R) -> Self
     impl<R: Rng> RngUtil for R

On a similar note, there are multiple instances in syntax and rustc
where there is trait defined, impl'd for a single type and used as a
@trait dynamic object, rather than just putting the functions on an
impl for the type and using the type without the dynamic indirection
(e.g. in libsyntax/ext/base.rs, the trait ext_ctxt and the struct
CtxtRepr). Would doing a similar transformation to remove the
indirection be desired?

I'm asking because there is quite a few occurrences of these patterns
through out the rust repo so there is quite probably something
non-obvious about them.


More information about the Rust-dev mailing list