Generally speaking this is legacy code that has not yet been updated.
On Mon, Apr 22, 2013 at 8:54 AM, Huon Wilson <[email protected]> wrote: > 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 > > to > > 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. > > > Huon > > ______________________________**_________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev> >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
