dsimcha wrote:
Ok, now that the new docs are up, I'm kind of curious about what's a fundamental
limitation vs. a todo. I assume the following are fundamental limitations,
since
CTFE has no concept of threading or global state and works by interpreting the
code, not executing it directly on the architecture it's being compiled for:
The function source code must be available to the compiler.
Fundamental limitation.
Executed expressions may not reference any global or local static variables
Fundamental limitation.
No synchronized or asm statements. (Since CTFE code is always effectively
single-threaded and doesn't allow global state anyhow, could we maybe make
synchronized statements effectively a no-op in CTFE?)
Asm fundamental, synchronized could be a no-op.
Casts which involve a reinterpretation of the underlying pattern of bits (eg,
from
int[] to float[]) are not permitted
Not sure. Would be tricky to implement in general.
C-style semantics on pointer arithmetic are strictly enforced.
Fundamental, and intentional.
Function parameters may not be C-style variadic
Not fundamental, this could be implemented fairly easily. But probably
shouldn't be encouraged, since it's not necessary.
The following look like they are simple matters of programming and could be
implemented eventually:
With statements, scope statements, try-catch-finally statements, throw
statements.
Delete expressions.
Classes and interfaces.
Correct. If you use them, the error message for all of these is "XXX is
not yet implemented in CTFE", whereas the others say "cannot be
interpreted at compile time". They'll all work eventually. (Not sure
about delete, it might not be good idea).
That said, this is a heck of a lot less limitations than CTFE used to have.
Great
job, Don!
Thanks. It's been possible to work on this because there are now so many
people fixing the critical compiler bugs. In particular, Kennytm has
been an enormous help. As well as a phenomenal number of patches, he's
also been posting PERFECT bug reports on CTFE issues.
== Quote from Don (nos...@nospam.com)'s article
Nick Sabalausky wrote:
Yet again, a new DMD release has broken my code, and other people's code,
too, just because of Phobos functions loosing their CTFE-ability. (strip(),
toLower(), etc... And yes, I did bring up the strip() regression on the beta
list, to no effect.)
The situation is, that prior to 2.054, use of Phobos in CTFE functions
has not been supported. No official statements have ever been made that
it was supported (and I've tried hard to publicize the fact that it was
not supported). There were some fundamental wrong-code bugs and severe
limitations in CTFE. And so although some Phobos functions seemed to
work in CTFE, most of them were not correct.
So, any Phobos function which used to work in CTFE in some old release
but doesn't any more is not a regression. It was just dumb luck, relying
on undefined behaviour, if any happened to work in a particular release.
This has changed with 2.054. Although there are still some restrictions
(no classes, many builtin functions aren't implemented), the fundamental
wrong code bugs are fixed. So any Phobos function which works in CTFE in
2.054, but fails in a future release, can be considered a regression.
We are now in a _completely_ different regime.
