Analogous to the typical OO problem where it's not clear which class a method should belong too.
Because I mistakenly believed that where clauses are less powerful I thought that the above choice had additional significance beyond code organisation, because it would affect the kind of constraints I could write. But they aren't so it doesn't matter :)
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, I got that whole thing totally wrong. I've removed that part of the post and linked to this discussion instead. Thankyou for de-confusing me :)
> The second argument can never be self. It's always the first.
I think we are talking past each other on this point. I'm thinking of the design-time choice between eg:
Analogous to the typical OO problem where it's not clear which class a method should belong too.Because I mistakenly believed that where clauses are less powerful I thought that the above choice had additional significance beyond code organisation, because it would affect the kind of constraints I could write. But they aren't so it doesn't matter :)