> Option and tuples count as data structures.

I'm aware.

> How? Special casing Eq?

No. I find it hard to see where the issue is... For instance, in C++ I can write the following:

```c++
class Seconds {
public:  
  Seconds(int value) : value_(value) {}
  bool operator==(const Seconds &other) {
     return *this == other;  
  }

private:
  int value_;
};

int main() {
  Seconds s = 10;
  bool b = 11 == s;
}
```

The compiler will look at the `11 == s` expression and will see that it's `int == Seconds`. It knows it can do `int == int` and will see if it can convert `Seconds` to `int` and will realize it can't. Then it knows it can do `Seconds == Seconds` and will consider can it convert `int` to `Seconds` and will realize it can because of the `Seconds` constructor. It will thus implicitly convert `int` to `Seconds` and perform the comparison.

So if rustc knows that `==` is `fn eq<T>(x: &T, y: &T) -> bool` and `&T` and `T` won't work, and `T` can be converted to `&T`, then perform the conversion and continue.

> That is how I see it, because types/values need to match for a general function call (including ==)

That's the part that needs to be extended. `&T` should be considered a `T` if needed since going from one to the other is free and safe.

I'm explaining implicit conversions here which I know you're aware of.

> This means that the example here doesn't work.

I can easily come up with another example. :)