> 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!
Agreed. The situation with regards to CTFE has really been improving. Thanks Don! - Jonathan M Davis