Time for Phobos CTFE-ability unittests...right? RIGHT?

[dsimcha]

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.

Executed expressions may not reference any global or local static variables

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?)

Casts which involve a reinterpretation of the underlying pattern of bits (eg, from
int[] to float[]) are not permitted

C-style semantics on pointer arithmetic are strictly enforced.

Function parameters may not be C-style variadic


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.


That said, this is a heck of a lot less limitations than CTFE used to have.  Great
job, Don!

== Quote from Don (nospam at 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.