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
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.
Thank you for the comments. A third (c) possibility is to change the way CTFE is done, avoiding some duplication in the compiler.
Wontfix: Builtin .reverse and .sort are shameful and will hopefully be removed from the language soon. The standard library functions work in CTFE now.