Yeah, any of these choices will work^. Well, the last choice shouldn't be a trait, really, just a standalone function.
Associated types would also help simplify this (note, if you have a trait Foo<A>, the trait can be implemented multiple times on the same type, with different A. If you have a trait Foo with associated type A, only one implementation will be allowed, the associated type is a property of the implementation)
^ In more complicated situations coherence may disallow one or more of those choices.
> the trait can be implemented multiple times on the same type, with different A
That was the intention - a function that dispatches on the type of both arguments (it probably shows that I secretly think of traits as typeclasses). I'm still trying to figure out what the implications of the above choices are.
> In more complicated situations coherence may disallow one or more of those choices.
I hadn't thought of that. If the trait is in another crate, does coherence require that the self type is in this crate or that all the types are in this crate? How do the coherence rules work if I don't have self type?
The general the coherence rules stop you from defining an implementation that could be possibly defined elsewhere.
The important take away implications are:
- you can not implement a trait defined in another crate for a type defined in another crate, unless the trait is parametrized by a type from the current crate
- you can't define overlapping implementations
Yeah, any of these choices will work^. Well, the last choice shouldn't be a trait, really, just a standalone function.
Associated types would also help simplify this (note, if you have a trait Foo<A>, the trait can be implemented multiple times on the same type, with different A. If you have a trait Foo with associated type A, only one implementation will be allowed, the associated type is a property of the implementation)
^ In more complicated situations coherence may disallow one or more of those choices.