This question came up in the pulls.
Given two different Tuple types, it is possible to run an
operator on said tuples, if the operator is legal for each
individual field in the tuple. For example.
//----
import std.typecons;
void main()
{
auto a = Tuple!( int, const(char)[])( 2,
"what".dup);
auto b = Tuple!(short, immutable(char)[])(cast(short)1,
"hello");
a = b;
assert(a == b);
assert(!(a < b));
assert(!(a < b));
assert(!(a > b));
}
//----
I'm not really sure if this was really ever meant to work this
way, or if the implementation got luck and allowed it. The
documentation isn't really very clear about it.
In any case, it begs the question: *Should* Tuples be allowed to
do this?
The rationale for them *not* being allowed is that the Types are
different, and for standard aggregate structs, this would not be
legal, *even if* each field can be cast from one to the other.
Why should Tuple allow it?
Stances on the matter?

This question came up in the pulls.
Given two different Tuple types, it is possible to run an
operator on said
tuples, if the operator is legal for each individual field in
the tuple.
For example.

Even if each field-wise operations is legal, the synthesis
operation of
individual results might not be obvious.
Kenji Hara

Hum...
I went to C++ to see how they do it. Apparently, in C++,
cross-tuple operations are fair game:
//----
#include <iostream>
#include <tuple>
int main()
{
std::tuple<int, int> a;
std::tuple<short, short> b;
a = b;
if (a == b)
std::cout << "hello" << std::endl;
if (a < b)
std::cout << "hello" << std::endl;
}
//----
If we follow the rule of "least surprise" and that "things which
are common behave the same", it might be safer to keep this
behavior.

If we follow the rule of "least surprise" and that "things
which are common behave the same", it might be safer to keep
this behavior.

equal and cmp and OnHash among tuples of the same type must be
supported if all the types they contain support those operations.
If you remove that behaviour tuples become much less useful.
What's worth discussing is the opposite, so if it's a good idea
to allow other operations among tuples if their types support
those operations.
Bye,
bearophile

What other operations are you thinking about? Maybe a generic
opDispatch?

There are various possible operations. But thinking better on the
topic, the most common operations I like to do on tuples are
things like unpacking them with a nice syntax, using them in a
switch(tuple1) statement, and sometimes using a transversal on an
array of tuples (this means collecting a field of all tuples of
an array). All three things have already bugzilla ERs.
Bye,
bearophile