[withoutboats]

It can be! And arguably people have leaned too hard on the decisions made in the std as an example: in std, everything is generic so that it can be inlined well, because std APIs underlie everything. At the application layer, this is not obviously what you want.

However, in many cases, a well designed generic API will be able take a trait object in the place of `T`. That way, at the application layer, you can decide to pass trait objects around, reducing code size and - maybe more importantly to you - compile times. cargo does this for example in some places where the performance regression is insignificant but it saves noticeable compile time.

Sometimes libraries accidentally don't set things up so that you can pass either a concrete `T` or a dynamically dispatched trait object to their APIs; we're hoping to find a way of making it less likely for this to go wrong in the future.

[nicoburns]

Something I've been thinking about a lot recently: would there be scope for a compiler mode which used virtual dispatch for generics (as well as trait objects) so as to speed up compile times? (and then you could compile the same code monomorphised for production).

[bbatha]

It's been proposed before: https://internals.rust-lang.org/t/idea-polymorphic-baseline-...

Its also fairly common to have code like:

   fn do_it(a: impl AsRef<i32>) {
      let a = a.as_ref();
      // do something with a
    }

That could be instead monomorphised to be

   fn _do_it(a: &i32) {
       // do something with a
   }

   fn do_it(a: impl AsRef<i32>) {
      let a = a.as_ref();
      _do_it(a)
   }

saving the inlining of _do_it's code bloat/generation penalty.

[nicoburns]

Hmm, interesting the Niko thinks that MIR optimisation passes and CraneLift are more likely to happen soon. I so dearly want faster Rust compile times!