[Retry] Add isHomogeneous and isHeterogeneous for Tuple

[MetaLang]

I managed to completely mess up my previous branch, so let's try this again.

[ghost]

Sorry to nitpick here, but are there any other synonyms we can use instead of these names? I don't think I'll ever be able to spell out "isHeterogeneous" right, it's way too complicated. (and please no autocomplete talk guys).

[ghost]

I'd prefer something like allSame or areAllSame or something similar, and if the user wants the opposite he can just use !allSame, as in:

static if (allSame!Tuple) { }

static if (!allSame!Tuple) { }

Whatever name we pick it should be simple enough to remember, and there's no need to add an opposite template when we can use !name.

[ghost]

Note that we have the isSame template in Phobos already so it's not unprecedented, although the template is private.

[MetaLang]

What about allSameTypes, or hasSingleType? Or, maybe go the other way with hasMultipleTypes / hasMultiTypes.

[monarchdodra]

Apologies, but why would anybody need either of these? Do you have a usecase? This looks useless/gratuitous to me.

---

Regarding the name, without looking at the pull, I thought these were meant for TypeTuple, where isHomogenous returned true if all the types where homogeneous (eg, all types, all values, or all aliases).

From an english/math point of view "homogeneous" != "all are same". But rather "all belong to the same familly".

[MetaLang]

Do you have a usecase

tupleToArray(T, A)(T tup, A[] arr)
if (isHomogeneous!T)
{
    //...
}

For one example, though I can imagine that this is just generally useful for working with Tuples.

I thought these were meant for TypeTuple

I suppose it would be better to add it to std.typetuple instead of std.typecons, because that'd work for both Tuple and TypeTuple. My reasoning for opening a pull for std.typecons is that it seems to me that Tuple is used much more than TypeTuple in general code that's not doing any TypeTuple-specific stuff (e.g., looping over a list of types). Putting it in std.typetuple and expecting people to know that it will work for Tuple as well didn't seem like a great idea to me considering the confusion over the different kinds of tuples in D.

..."homogeneous" != "all are the same". But rather "all belong to the same family"

Please provide evidence for this assertion, as it means "all of the same kind" in any dictionary/textbook I'd care to look through. I agree it's too long, though, and the template should have a shorter name.

[monarchdodra]

Please provide evidence for this assertion

I don't know if this is "evidence", but form thefreedictionary.com, thesaurus:

Adj. 1. homogenous - all of the same or similar kind or nature; "a close-knit homogeneous group"

But you said it yourself: "all of the same kind": "same kind" != "same". EG: they bare similarities, but aren't exactly similar.

[MetaLang]

Whoops, should say "allTypesSame".

[JakobOvrum]

For one example, though I can imagine that this is just generally useful for working with Tuples.

This use-case can be done (in an arguably better way) with CommonType instead:

void tupleToArray(T, U)(T tup, ref U[] arr) if(isTuple!T && !is(CommonType!(U, T.Types) == void))
{
    ...
}

[monarchdodra]

Do you have a usecase

tupleToArray(T, A)(T tup, A[] arr)
if (isHomogeneous!T)
{
    //...
}

Hum... but what is tupleToArray's usecase? I had thought of that too, but see no use for it? Are there any other usecase for it? If not, then you might well just write tupleToArray...

[MetaLang]

...what is tupleToArray's usecase?

General usefulness, and also completeness. This currently doesn't work:

import std.conv;
import std.typecons;
void main()
{
    auto t = tuple(0, 0, 0);
    auto a = to!(int[])(t);
}

Being able to convert a tuple to an array is generally useful, I think, and is also useful in generic code where you don't know what types you're working with. As long as the tuple is homogeneous, I think it's perfectly valid to want to turn it into an array, or vice-versa. I think it'd be nice if we had full generality, allowing tuples to be used as ranges. You could probably do it with Algebraic...

[MetaLang]

This use-case can be done (in an arguably better way) with CommonType instead:

void tupleToArray(T, U)(T tup, ref U[] arr) if(isTuple!T && !is(CommonType!(U, T.Types) == void))
{
...
}

Yes, I agree that's better. I think it's generally useful to know if all the types of a tuple are the same just from its type, though. Hmm, maybe this would be better for typetuple instead.

[JakobOvrum]

I think it's generally useful to know if all the types of a tuple are the same just from its type, though. Hmm, maybe this would be better for typetuple instead.

This might very well be true, but all the use cases I can think of (and have used) are better solved with CommonType. It would be nice to have at least one solid example of how isHomogeneous provides real value.

Regardless, I also think it's better as an operation on in-built type tuples (urgh, I thought we decided to rename them already!). It's more general that way.

[monarchdodra]

Being able to convert a tuple to an array is generally useful

I don't see why you'd have a tuple to begin with, if a static/dynamic array would have done the job just as well.

and is also useful in generic code where you don't know what types you're working with

If you are in generic code, I don't see why you'd write code for this special case, when you have to handle the generic case anyways.

You might yet prove me wrong, but I'm still not convinced this is of any use :/

[monarchdodra]

You can replace this block with:

enum isSameTypeAsHead(U) = is(U == types[0]);

[MetaLang]

This might very well be true, but all the use cases I can think of (and have used) are better solved with >CommonType. It would be nice to have at least one solid example of how isHomogeneous provides real value.

I was going to talk some more about converting a tuple to an array, but it seems that std.array.array does this already... I didn't know about this. Why then, is there no equivalent functionality for std.conv.to as well? It could just call std.array.array to construct its output.

Regardless, I also think it's better as an operation on in-built type tuples (urgh, I thought we decided to rename >them already!). It's more general that way.

At this point, I agree. I'll close this in favour of a pull for std.typetuple.