www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - strange CFTE issue

reply Inquie <Inquie data1.com> writes:
If I do something like

enum X = Methods!(C);

foreach(x; X)
{
     mixin(x);
}

I get an error about x not being a compile time variable. (code 
above is simplified, the error has nothing to do with the form 
but of the foreach(x )

but if I wrap it in a function it works

string foo()
{
enum X = Methods!(C);
string y = "";
foreach(x; X)
{
    y ~= x;
}
  return y;
}

mixin(y);

The only diff, of course, is the foreach in the first case mixes 
in on each iteration, while in the second it doesn't... but it 
shouldn't matter. in both cases x is the same.. and it definitely 
is a compile time constant in both. (Methods is just a wrapper on 
__traits(allMembers) but does some manipulation (stole the code 
from somewhere on the forum))
Mar 14
parent reply ag0aep6g <anonymous example.com> writes:
On 03/15/2017 03:01 AM, Inquie wrote:
 If I do something like

 enum X = Methods!(C);

 foreach(x; X)
 {
     mixin(x);
 }

 I get an error about x not being a compile time variable. (code above is
 simplified, the error has nothing to do with the form but of the
 foreach(x )
"Compile time variable" may be misleading here. The compiler does not try to figure out what values are actually constant at compile time. Rather, the language defines some specific cases where it's guaranteed that a value is a compile-time constant. Only then can you use it in static contexts such as mixins. Other values are rejected, even if they would turn out be constant on a closer look. `foreach` is mostly a run-time feature. There is a special case when you iterate over a "compile-time list" [1] (aka AliasSeq, formerly TypeTuple). In that case, the loop variable is recognized as a constant. That variant of `foreach` is also dubbed a "static foreach" (even though the `static` keyword is not used). Note that it's not a "static foreach" when you iterate over an array, no matter if that array is constant at compile time or not. So this works: import std.meta: AliasSeq; foreach (x; AliasSeq!("int foo;", "double bar;")) mixin(x); But this doesn't: foreach (x; ["int foo;", "double bar;"]) mixin(x); This is expected and works as intended. Without the definition of your `Methods` template, I can't say for sure if you're hitting this or if something else is going on. But if your `X` is an array, this is it.
 but if I wrap it in a function it works

 string foo()
 {
 enum X = Methods!(C);
 string y = "";
 foreach(x; X)
 {
    y ~= x;
 }
  return y;
 }

 mixin(y);
(I'm assuming that last line should be `mixin(foo());`.) The return value of `foo` is recognized as a compile-time constant there, because you call it in a context that forces it. This is called CTFE. Note that you cannot assign the result of `foo()` to a variable first: string y = foo(); /* no CTFE */ mixin(y); /* no go */ That's because `y` is a normal variable, which is not a recognized compile-time constant. The value could of course be evaluated at compile-time, but the compiler doesn't attempt CTFE opportunistically.
 The only diff, of course, is the foreach in the first case mixes in on
 each iteration, while in the second it doesn't... but it shouldn't
 matter. in both cases x is the same.. and it definitely is a compile
 time constant in both.
To the compiler it's not a "compile-time constant" in either of them (in a rather specific sense of the term "compile-time"). During CTFE, run-time rules apply. So in `foo`, `x` is a normal variable. The same rules apply as for actual run-time variables. Only the return value of `foo` is seen as a compile-time value by the compiler. You're not the first one who stumbles over this meaning of "compile time". CTFE happens at compile time, and has "compile time" in the name, but during CTFE you're actually dealing with "run time" values that might never see the actual run time. Maybe these things could use some better names. [1] https://dlang.org/ctarguments.html
Mar 14
parent reply Inquie <Inquie data1.com> writes:
On Wednesday, 15 March 2017 at 03:40:42 UTC, ag0aep6g wrote:
 On 03/15/2017 03:01 AM, Inquie wrote:
 If I do something like

 enum X = Methods!(C);

 foreach(x; X)
 {
     mixin(x);
 }

 I get an error about x not being a compile time variable. 
 (code above is
 simplified, the error has nothing to do with the form but of 
 the
 foreach(x )
"Compile time variable" may be misleading here. The compiler does not try to figure out what values are actually constant at compile time. Rather, the language defines some specific cases where it's guaranteed that a value is a compile-time constant. Only then can you use it in static contexts such as mixins. Other values are rejected, even if they would turn out be constant on a closer look. `foreach` is mostly a run-time feature. There is a special case when you iterate over a "compile-time list" [1] (aka AliasSeq, formerly TypeTuple). In that case, the loop variable is recognized as a constant. That variant of `foreach` is also dubbed a "static foreach" (even though the `static` keyword is not used). Note that it's not a "static foreach" when you iterate over an array, no matter if that array is constant at compile time or not. So this works: import std.meta: AliasSeq; foreach (x; AliasSeq!("int foo;", "double bar;")) mixin(x); But this doesn't: foreach (x; ["int foo;", "double bar;"]) mixin(x); This is expected and works as intended. Without the definition of your `Methods` template, I can't say for sure if you're hitting this or if something else is going on. But if your `X` is an array, this is it.
 but if I wrap it in a function it works

 string foo()
 {
 enum X = Methods!(C);
 string y = "";
 foreach(x; X)
 {
    y ~= x;
 }
  return y;
 }

 mixin(y);
(I'm assuming that last line should be `mixin(foo());`.) The return value of `foo` is recognized as a compile-time constant there, because you call it in a context that forces it. This is called CTFE. Note that you cannot assign the result of `foo()` to a variable first: string y = foo(); /* no CTFE */ mixin(y); /* no go */ That's because `y` is a normal variable, which is not a recognized compile-time constant. The value could of course be evaluated at compile-time, but the compiler doesn't attempt CTFE opportunistically.
 The only diff, of course, is the foreach in the first case 
 mixes in on
 each iteration, while in the second it doesn't... but it 
 shouldn't
 matter. in both cases x is the same.. and it definitely is a 
 compile
 time constant in both.
To the compiler it's not a "compile-time constant" in either of them (in a rather specific sense of the term "compile-time"). During CTFE, run-time rules apply. So in `foo`, `x` is a normal variable. The same rules apply as for actual run-time variables. Only the return value of `foo` is seen as a compile-time value by the compiler. You're not the first one who stumbles over this meaning of "compile time". CTFE happens at compile time, and has "compile time" in the name, but during CTFE you're actually dealing with "run time" values that might never see the actual run time. Maybe these things could use some better names. [1] https://dlang.org/ctarguments.html
Thanks, it explains it, but there is one difference. The array is assigned to an enum, so surely the compiler can figure that out? It should be similar to AliasSeq. I could probably wrap AliasSeq around it and it work or convert it to an AliasSeq. Seems like an issue with the compiler. Remember, it's
 enum X = Methods!(C);

 foreach(x; X)
 {
     mixin(x);
 }
and not
 string X = Methods!(C);

 foreach(x; X)
 {
     mixin(x);
 }
that should be quite difference and the static foreach in the first case and non-static foreach in the second. Essentially what you are saying is that if I were to have Methods! return an AliasSeq then it would work. It is a CTFE that returns an array. If there is a function that can convert the the array to an AliasSeq of tuples there should be no problem, although I don't see how to do that, it should be possible? But, this all then seems to be skirting the fact that the loop is still over a compile time constant(enum or AliasSeq, shouldn't matter) and should work.
Mar 15
parent reply ag0aep6g <anonymous example.com> writes:
On 03/15/2017 02:00 PM, Inquie wrote:
 Thanks, it explains it, but there is one difference. The array is
 assigned to an enum, so surely the compiler can figure that out? It
 should be similar to AliasSeq.
The enum array is similar to an AliasSeq in that you can them both in contexts that require compile-time constants. But that doesn't mean that every context in which you put them gets evaluated at compile time. Different example: If you write `if (true)` that's a run-time conditional even though `true` is a constant. By the language rules, the check is done at run time. It may of course be optimized out, but the language doesn't care about that. There's also a `static if`. If you write `static if (true)`, that check is done at compile time, by the language rules. That means you can only put compile-time constants as the condition of a `static if`. In other words, the `static if` forces compile-time evaluation of its condition. This "forcing of compile-time evaluation" is how things work. Compile-time evaluation is only attempted when it's forced by the context. It's not attempted when run-time evaluation is possible. `enum`, `mixin`, and `static if` force compile-time evaluation. With `foreach` it's only forced when looping over an AliasSeq, because you can't do that at run-time. As for why this is so: Consider that a run-time loop can take a long time (hours, days, ...) even if it's over a constant array. It's expected that the generated program runs for a long time. It would be surprising if the compilation were to take that long time, just because the compiler saw that it's possible. By the way, I'd love to see an actual `static foreach`, with the `static` keyword. I'd have it work similar to `static if` and force compile-time semantics. Then (slowly) deprecate using plain `foreach` on AliasSeqs. Would make D code clearer, in my opinion. But this might have non-obvious issues. I haven't thought too hard about it. [...]
 Remember, it's

 enum X = Methods!(C);

 foreach(x; X)
 {
     mixin(x);
 }
and not
 string X = Methods!(C);

 foreach(x; X)
 {
     mixin(x);
 }
that should be quite difference and the static foreach in the first case and non-static foreach in the second.
It would make a difference with the hypothetical `static foreach`, which would accept the first one but reject the second one. With plain `foreach` it doesn't matter. Ignoring the body, the loop can be done at run-time in both versions, so that's what the compiler tries to do. Compile-time evaluation must be requested by the programmer. The compiler doesn't attempt it eagerly.
 Essentially what you are saying is that if I were to have Methods!
 return an AliasSeq then it would work.
Yup.
 It is a CTFE that returns an
 array.
You might use the term "CTFE" correctly here, but you also might use it incorrectly. Just to clarify the term, if `Methods` looks this: template Methods(T) { enum Methods = /* ... whatever ... */; } or like this: enum Methods(T) = /* ... whatever ... */; then it's not a function, but a template. CTFE may happen in the "whatever" part, but `Methods` itself does not go through CTFE as it's not a function. But if `Methods` looks like this: string[] Methods(T)() { /* ... whatever ... */ } then it is a function and does go through CTFE.
 If there is a function that can convert the the array to an
 AliasSeq of tuples there should be no problem, although I don't see how
 to do that, it should be possible?
Phobos has it: std.meta.aliasSeqOf "converts an input range [...] to an alias sequence." [1] Applied to your code: enum X = ["int foo;", "double bar;"]; foreach(x; aliasSeqOf!X) { mixin(x); /* works */ }
 But, this all then seems to be skirting the fact that the loop is still
 over a compile time constant(enum or AliasSeq, shouldn't matter) and
 should work.
Yeah, no. A compile-time constant being used doesn't mean anything. It's the context in which it is used that forces compile-time evaluation.
Mar 15
parent ag0aep6g <anonymous example.com> writes:
 Phobos has it: std.meta.aliasSeqOf "converts an input range [...] to an
 alias sequence." [1]
Woops, forgot to give the URL for that "[1]". Here it is: http://dlang.org/phobos/std_meta.html#aliasSeqOf
Mar 15