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?

2013/2/12 monarch_dodra <monarchdodra@gmail.com>

> 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

On Tuesday, 12 February 2013 at 14:35:18 UTC, kenji hara wrote:
> 2013/2/12 monarch_dodra <monarchdodra@gmail.com>
>
>> 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.

monarch_dodra:

> 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

On Tuesday, 12 February 2013 at 21:43:00 UTC, bearophile wrote:
> monarch_dodra:
>
>> 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.

Did you really mean "Tuples of the same type"? Because I don't think that was bein argued, and I agree with the conclusion.

> 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?

monarch_dodra:

> 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