I have the following situation: I have two traits, lets call them T1 and T2. For T2 I have many implementations and I want users of my library to also be able to add implementations to it.

For T1 all implementations are generic over various sub-traits of T2 so something like

trait SubTrait1: T2 { ... }
struct ConcreteT1<T: SubTrait1> { ... }
impl<T: SubTrait1> T1 for ConcreteT1<T> { ... }

Now what I want in the end is that a potential application can select at runtime an implementation of T1 by selecting an implementation of T2 and selecting a generic struct such that the generic struct with the selected T2 implementation implements T1.

Now I want this system to be extendable, which means that users can:

1. Add new T2 implementations that implement various sub-traits
2. Add new Subtraits of T2
3. Add new generic structs that implement T1 and the generic argument is bound by one of the subtraits of T2.

How can I approach this? Is working with traits even the right thing (given that they are purely compile-time while I want the two "algorithms" to be selectable at runtime). On the other hand I want to avoid having to implement logic for any pair of algorithm, I want to use the power of trait abstractions to group together T2 implementations and their behaviors.

3 posts - 2 participants

Read full topic