This is a current limitation of the coherence rules. I don’t know if you’ve heard of specialization, but its a new feature which would allow you to write overlapping impls as long as they meet a certain ordering of ‘specificity’ (for example, an impl for
u32 is more specific than an impl for
T: Foo + Bar is more specific than
T: Foo). Every use of the trait will always look up the most specific impl for that type.
Specialization doesn’t cover this use case yet -
T: HasEmployees and
T: SomeOtherTrait don’t have an ordering of specificity - what if a type implements both
SomeOtherTrait? There are two solutions to this problem, both of which are still in the ‘design / RFC’ phase (no implementation yet):
- “Intersection impls” - if two impls overlap, but one is not a subset of the other, you can have them both as long as you provide an impl for their intersection. For example, one impl for
T: HasEmployees, one for
T: SomeOtherTrait, and a third for
T: HasEmployees + SomeOtherTrait.
- “Mutual exclusion” - maybe it doesn’t make sense for a single type to implement both of these traits. This would be a way to say a single type can’t implement both of two traits (for example, imagine a
UnsignedInt trait - it wouldn’t make sense for a single type to be both signed and unsigned). Then these impls wouldn’t be overlapping at all.