here we are saying: We can define a Remote_Eval_T. For every object that implements trait Remote_Eval_T, it has an associated Context_T, which we later use in one of the functions.
We can't write the above code, so instead we have to write:
struct Bar {}
struct Foo {}
impl Remote_Eval_T for Bar {
Context_T = Bar_Context_T here
}
impl Remote_Eval_T for Foo {
Context_T = Foo_Context_T here
}
I.e. the Context_T is not a global constant, but depends on the struct that implements Remote_Eval_T
In particular, Bar_Context_T might have something like fn punch while Foo_Context_T has something like fn fire_rocket
Only guessing here, but the difficulty may come when you want to use dyn RemoteEval, as the associated types have to match (dyn RemoteEval<Context = SomeType>). One way around that is you end up with a dyn RemoteEval<Context = Box<dyn Context>> or the like.
This will probably come up in the language more once we get RPITIT [1], as the return types are effectively associated types [2]. See here for example.
Thanks for trying to help. This question is botched, due to my fault, as I tangled a number of issues (still not sure how to frame the question). Suppose we have something like this:
crateA:
trait Tank_T:
fire_missile
move
trait Solider_T:
punch
move
crate_B:
impl Remote_Eval_T for Blah { using Solider_T }
impl Remote_Eval_T for Blah2 { using Tank_T }
crate_C:
struct RifleMan {}; impl Solider_T for RifleMan;
struct SwordMan {}; impl Solider_T for SwordMan;
struct LightTank {}; impl Tank_T for LightTank;
struct HeavyTank {}; impl Tank_T for HeavyTank;
Then suppose (for external reasons), we want crate B to only depend on crate A, but not depend on crate C.
So we now have the problem that Remote_Eval_T only has access to the traits Solider_T and Tank_T, but not the actual impls.
TLDR: There is this tangled mess I failed to capture in the original question.