What is the cited problem with using generic type parameters in trait objects?

Question

I am reading Object Safety Is Required for Trait Objects and I don't understand the problem with generic type parameters.

The same is true of generic type parameters that are filled in with concrete type parameters when the trait is used: the concrete types become part of the type that implements the trait. When the type is forgotten through the use of a trait object, there is no way to know what types to fill in the generic type parameters with.

I am trying to code an example but I can't make sense of it. Generic type parameters for what?

I tried to make a trait object out of a parameterized trait, but once the parameter is given a concrete value it works just fine:

trait Creator<T> {
    fn create(&self) -> T;
}

struct CreationHouse {
    creators: Vec<Box<dyn Creator<u32>>>
}

struct NumCreator { seed: u32 }

impl Creator<u32> for NumCreator {
    fn create(&self) -> u32 {
        return self.seed;
    }
}

fn main() {
    let ch = CreationHouse{
        creators: vec![Box::new(NumCreator{seed: 3})]
    };
}

(Compiles well, except "unused" warnings)

What I don't get is what does it mean "generic type parameters that are filled in with concrete type parameters when the trait is used" and how could the generic types be lost (as the trait "carries" them with itself). If you could write an example of the case described in the paragraph I'd be grateful.

Answer 1

what does it mean "generic type parameters that are filled in with concrete type parameters when the trait is used"

An example that won't work is when the type parameter is part of a method:

trait Foo {
    fn foo<T>(t: T) {}
}

When a function has a type parameter, Rust will monomorphize the function (make a new copy) for each type that it is actually called with. This isn't compatible with trait objects because Rust doesn't know which impl the method belongs to until runtime.

Answer 2

As @PeterHall mentioned, with a generic method the trait cannot be object-safe.

The reason, it turns out, is simply an implementation limitation.

Efficient dispatch to the correct implementation of a trait method is achieved by using a virtual-table, which is essentially a table of pointer-to-functions. Each method in the trait object gets one slot in the virtual-table to store one pointer-to-function.

On the other hand, a generic function or method is no function or method at all. It's a blueprint to create as many different functions or methods as one wishes by substituting the generic parameters with actual, concrete, parameters.

This means that it is not possible to have a pointer-to-function for fn foo<T>() -> T; as there is no code for it, instead you may have a pointer-to-function for one fn foo<i32>() -> i32, and another pointer-to-function for one fn foo<String>() -> String, and another...

The impossibility to have a pointer-to-function, and thus a v-table entry, for a generic method makes it impossible to call that method via run-time dispatch, that is, on a dyn Trait.

It is notable that other languages also suffer the same restriction, for the same reasons; C++ cannot have template virtual methods either, for example.