Thanks @OzieGamma for the PR!

@stephentoub @terrajobst The change looks good to me. I'll let you comment on public API question.
In particular, this introduces a difference between ValueTuple and Tuple. Should we add similar operators to System.Tuple too?

FYI for @KevinRansom @gafter @VSadov

I don't think we (you ?) can add == and != to System.Tuple. Since it is a reference type, == is already defined. That would introduce breaking changes in the public API.

This compiles fine:

Tuple<string> a = new Tuple<string>("");
Tuple<string> b = new Tuple<string>("");

if (a == b)
{
}

On the other hand, as mentioned above, users will potentially use ValueTuple a LOT. Not having == or != might be frustrating ...

NB: I haven't played around with the new language features yet. I don't know in practice how likely I will need/want == or !=

@OzieGamma You're right about backward compatibility issue on System.Tuple.
Let me check with some folks and get back to you on this PR.

I have two main concerns with adding operator== and operator!= to System.ValueTuple. Both of them boil down to the assertion that these operators should act as if operating using == on the underlying elements. But you can’t program that into the ValueTuple type, because the implementation of the generic type doesn’t know what operator== to apply to the elements. For example

1. Using object.Equals(x, y) isn’t correct, because it isn’t the same as operator==. To take an example from our platform, double.NaN.Equals(double.Nan), but !(double.NaN==double.NaN). So (double.NaN == double.NaN) would give a different result from ((double.NaN, 0) == (double.NaN, 0)) if we implement the latter using object.Equals(); the former would be false while the latter would be true. I believe that is not what we want.
2. We would want the == operator on tuples to apply whenever an underlying operator== can be found to apply on the elements, pointwise. If we do it in the language+compiler (now or in the future), we can make ((long)1, (byte)2) == ((short)1, (int)2) be true (not a compile-time error because no operator== can be found). However, there is no way to express that in source.

In short, I believe that adding support for operator== and operator!= to the sources of the ValueTuple libraries would be locking us in to the wrong semantics for what we would want the behavior to be.

@gafter Your points make complete sense. I'll propose this on the Roslyn repo then.

I