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

Don nospam at nospam.com
Sat Jul 30 12:09:48 PDT 2011


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 (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.
> 


More information about the Digitalmars-d mailing list