Comment #0 by bearophile_hugs — 2010-04-05T05:32:09Z
bool foo(int[] arr) {
arr.reverse;
return arr == [2, 1];
}
enum bool r = foo([1, 2]);
void main() {}
dmd 2.042 gives:
test.d(2): Error: cannot evaluate _adReverse(arr,4u) at compile time
test.d(5): Error: cannot evaluate foo([1,2]) at compile time
test.d(5): Error: cannot evaluate foo([1,2]) at compile time
Comment #1 by clugdbug — 2010-04-10T21:52:53Z
Note that ANY call to the runtime cannot be be interpreted in CTFE (because source code is not available). This bug, like bug 4021, is an enhancement request.
The spec specifically says that .dup, .length, .keys, and .values are the only built-in properties which are supported in CTFE. To support these others, they would need to be (a) moved out of the runtime; or (b) special-cased in the interpreter. And case (b) is not going to happen.
In 2.043, this gives the error message:
crash.d(38): Error: _adReverse cannot be interpreted at compile time, because it
has no available source code
crash.d(41): Error: cannot evaluate foo([1,2]) at compile time
crash.d(41): Error: cannot evaluate foo([1,2]) at compile time
which I think is slightly improved from before -- it at least explains that the missing source code is the reason why it cannot work.
Comment #2 by bearophile_hugs — 2010-04-11T04:31:42Z
Thank you for the comments. A third (c) possibility is to change the way CTFE is done, avoiding some duplication in the compiler.
Comment #3 by clugdbug — 2011-11-02T17:43:02Z
Wontfix: Builtin .reverse and .sort are shameful and will hopefully be removed from the language soon. The standard library functions work in CTFE now.