So, I have been building a little library as a coding exercise, and decided to maybe create a "Pair" type.

By Pair, in this context, I mean a pair of numbers, like 2D vectors and 2D coordinates.

To encompass these two possibilities I decided to create a couple marker structs, both implementing a marker trait `PairKind`

to differentiate the implementations of addition and subtraction of Coordinates vs Vectors.

For example, a `Pair<Coordinate>`

plus a `Pair<Vector>`

would return a `Pair<Coordinate>`

,

a `Pair<Coordinate>`

subtracted from another `Pair<Coordinate>`

would return a `Pair<Vector>`

, etc.

As part of all my implementations, I thought it would be a good idea to implement conversions between these kinds of pairs, in case I need to reinterpret between these kinds of pairs.

A prototype of this code would be the following:

`impl<T: PairKind, U: PairKind> From<Pair<U>> for Pair<T> { .... }`

Now, this implementation would work perfectly in theory, given there wasn't already an `impl<T> From<T> for T`

in the standard library. These implementations do indeed overlap.

Now, given I don't control the standard library, I cannot turn the standard library's implementation into a specialization of my implementation, or in other words, make my implementation a generalization of the standard library's. (AFAIK)

Thus an Idea was born in my head. What If I could force T and U not to be the same?

An implementation as such would not overlap with the existing impl:

`impl<T: PairKind, U: PairKind> From<Pair<U>> for Pair<T> where T != U { .... }`

One specific way of looking at this idea is creating mutually exclusive generic parameters, where T and U cannot be resolved to the same type.

Another more general way of looking at it is being able to exclude specific types in a generic bound, which in this specific case means excluding whatever type U happens to be, from the generic T.

I have attempted replicating this second idea by creating a "Is" trait, which would only be implemented for "Self == T" and not for any other type.

However, on creating this short snippet of code, which doesn't even encompass the whole idea, using #![feature(negative_impls)], the compiler told me that I couldn't implement both `Is<T>`

and `!Is<T>`

for `T`

, which is not what I was doing at all...

```
trait Is<T> {}
impl<T> Is<T> for T {}
impl<T,U> !Is<U> for T where U: !Is<T> {}
```

AFAIK this idea is not negative impls alone, not negative trait bounds alone, nor specialization, nor dependent types.

Am I missing something here?

Has anyone suggested this idea before?

Is this potentially a new (somewhat useless) language feature?

Appreciate any pointers that could get me on my way to figuring this out.