Bug 4064 – [CTFE] array.reverse doesn't work

Status
RESOLVED
Resolution
WONTFIX
Severity
enhancement
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
x86
OS
Windows
Creation time
2010-04-05T05:32:00Z
Last change time
2015-06-09T05:13:46Z
Keywords
rejects-valid
Assigned to
nobody
Creator
bearophile_hugs

Comments

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.