On Monday, 8 July 2013 at 12:11:36 UTC, Dicebot wrote:
On Monday, 8 July 2013 at 12:08:44 UTC, JS wrote:
the issue with the foreach is still under question though,
when I try to use a for loop with i and access TT[i] I get an
error about i not being compile time readable. (maybe this is
because of how the type tuple is defined? possibly need a
index method to get the value?)
Because i is not a compile-time value, it is a normal variable.
And TT is a type tuple, pure compile-time entity. You really
need to study the documentation on this topic or frustration
will continue.
This has nothing to do with it...
string name = "Value"~((i==0) ? "" : (to!string(i)));
i++;
works, but
string name = "Value"~((i==0) ? "" : (to!string(i++)));
but doesn't....
It is a matter of placement of the increment operation on i that
is breaking the code and has nothing to do with your default
answer of "you don't know how CTFE's work, read the docs!" and
"... it's not a compile-time variable".
If i's not possible to use at compile time then none of the
following code examples should work
One could argue that depending on how to!string works could be
the issue, but this has nothing to do with i, which is what you
have stated, but to!string.
If it is to!string or templates in general that are the issue
then it is confusing to have the same syntax for compile time and
runtime but some common runtime syntax doesn't work.
e.g.,
int x = 0;
writeln(x);
to!string(x++);
writeln(x);
works fine at run-time, but to!string(i++) fails and
to!string(i); i++; works in CTFE...
So, either this is what you were getting at but didn't explain it
well(making the issue about i when it is about CTFE templates) or
you didn't understand the issue yourself.
int i = 0;
foreach(t; T)
{
string name = "Value"~((i==0) ? "" : (to!string(i)));
i++;
}
vs
int i = 0;
foreach(t; T)
{
string name = "Value"~((i==0) ? "" : (to!string(i++)));
}
vs
foreach(i, t; T)
{
string name = "Value"~((i==0) ? "" : (to!string(i)));
}
all are suppose to do the same thing and are all essentially
semantically identical... they should do the same. (at least
according to your logic and the compiler error message that says
the issue is with i)
