So... did anyone think that my idea (of doing multiple-inheritance by separating the responsibilities of providing functionality and providing data between the trait and the type which implements the trait) would warrant an enhancement request at github? Or how do these things tend to work around here? (I've done plenty of bug/enhancement reporting for D, but I know that language fairly well whereas I've just barely read the Rust tutorial/manual).
On 2013-11-15, at 14:48, Oren Ben-Kiki <[email protected]> wrote: > Thanks for the explanation! So virtual function calls are kept to the > absolute theoretical minimum, that's very good to know. > > In my case I have one crate for some "infrastructure" and another crate for > the "application" using it (there would be several of these). I guess having > two copies isn't that bad. > > > On Fri, Nov 15, 2013 at 2:30 PM, Daniel Micay <[email protected]> wrote: > On Fri, Nov 15, 2013 at 6:54 AM, Oren Ben-Kiki <[email protected]> wrote: > > > > That would be awesome, if it were true; it is quite a trick to pull that off > > when the default methods are implemented in a different crate. Can someone > > provide an authoritative answer on this? > > > > Also, C++ faces the problem of providing a single copy of monomorphised > > functions (for templates). This is done during the link phase and AFAIK is > > one of the causes of C++ links taking a painfully long time. Will Rust > > suffer from the same problem? > > Rust serializes any generic or inline functions to an AST stored in > the crate metadata and will re-compile them as-needed per-crate. > > In both Rust and C++, you end up with one copy of these at runtime for > each dynamically linked shared object. With C++ templates, the linker > or link-time optimization discards duplicate instantiations across > compilation units. > > Rust doesn't have compilation units smaller than a crate so there is > no equivalent functionality. If you use crates as compilation units to > make compiles incremental/parallel, the situation is much worse than > C++ as you'll have many duplicates and they won't even go away with > link-time optimization until `mergefunc` works. > > There's almost no point in doing anything but a massive crate at this point... > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
