This topic pops up frequently in D.learn when one needs to pass several distinct TypeTuple's as template arguments. Auto-expansion behavior of existing TypeTuple does not make it possible because two will be merged into single argument list.
No, those are quite different. `std.typecons.Tuple` defines runtime tuple (struct). It can be CTFE'ed of course, but it can't contain types (in TypeTuple sense) or aliases (completely), only values and value meta-data.
Proposed `Group` acts exactly like `TypeTuple` but do not auto-expand.
Comment #4 by public — 2013-10-12T14:52:15Z
If TypleTuple comparison would have been legal, one could say that `Group!(int, double, foo).expand == TypeTuple!(int, double, foo)`
Comment #5 by andrej.mitrovich — 2013-10-12T14:55:06Z
(In reply to comment #3)
> No, those are quite different. `std.typecons.Tuple` defines runtime tuple
> (struct). It can be CTFE'ed of course, but it can't contain types (in TypeTuple
> sense) or aliases (completely), only values and value meta-data.
>
> Proposed `Group` acts exactly like `TypeTuple` but do not auto-expand.
Right.. well with Group you end up having a third tuple kind. I think it's best that we wait for a language implementation of tuple syntax (see http://wiki.dlang.org/DIP32).
Comment #6 by public — 2013-10-12T15:05:25Z
It is not a 3d kind of tuple, it is just another syntax for existing TypeTuple. Considering outcome of last tuple discussion threads any changes in that domain won't come any time soon and this small addition allows to implement certain algorithms right here and now.
I personally don't mind keeping it in "stdx" part of my projects but it is mentioned quite frequently as a necessary feature [citation needed].
Also DIP32 addresses different issues and won't change the fact that both expanding and non-expanding tuples are needed in different places.
Comment #7 by code — 2013-10-12T15:45:59Z
I wonder whether it is worth adding this as an officially supported kind of tuple, or if we should encourage making creative use of the current syntax to keep the complexity low: (untested, just typed it up to illustrate the principle of nesting templates)
---
template isEqual(T...) {
template to(U...) {
static if (T.length == U.length) {
static if (T.length == 0) {
enum to = true;
} else {
enum to = isSame!(T[0], U[0]) && isEqual!(T[1 .. $]).to!(U[1 .. $])
}
} else {
enum to = false;
}
}
}
static assert(isEqual!(1, 2, 3).to!(1, 2, 3));
---
Comment #8 by public — 2013-10-13T03:48:30Z
Main problem with nesting is that it does not allow algorithms with variadic amount of tuples.
Comment #9 by robert.schadek — 2024-12-01T16:18:55Z