Jonathan M Davis wrote:
On 2011-07-12 17:16, Nick Sabalausky wrote:
"Jonathan M Davis" <jmdavisp...@gmx.com> wrote in message
news:mailman.1576.1310513383.14074.digitalmar...@puremagic.com...
On 2011-07-12 16:17, Andrej Mitrovic wrote:
I don't understand what strip() could be doing to break CTFE anyway?
Don has been making huge changes to CTFE. Stuff that didn't used to
compile,
now complie. Stuff which compiled but shouldn't have now doesn't compile.
There's probably stuff which used to compile and should still compile
which
doesn't compile now too. But with all of those changes, I'm not sure that
it's
at all reasonable to expect CTFE-ability to be stable. It should be
heading in
that direction, but I'm not sure how stable Don considers it. Certainly,
strip
could be failing for a perfectly legitimate reason, or it could be a bug.
I
have no idea. But with all of the changes that have been being made to
CTFE,
I'm not at all surprised if stuff has quit working. There's probably more
that
works now that didn't before, but with all of the recent changes,
breakage doesn't surprise me one bit.
I definitely expected that in 2.053, since that's the version that had the
CTFE overhaul. But it's not being re-overhauled in each version after
2.053 - just bugfixes and added features. So at this point, I think it's
reasonable to expect that any CTFE changes that break Phobos code should be
fixed before release, even if only a temporary fix, in either the CTFE
engine or in the Phobos code that was broken.
Well, regardless of whether CTFE is still having a major overhaul, there's
still plenty of work being done on it. If you look at the changelog, you'll
see that there are a lot of CTFE-related changes, and I know that more CTFE
changes are in the works for 2.055 based on what Don has said. So, it doesn't
surprise me at all that issues with it are cropping up. And unless Don is
willing to say that we're going to guarantee the CTFEability of functions,
then there will be no guarantees of any functions remaining CTFEable, and
we're definitely not going to test that functions stay CTFEable.
2.053 fixed the fundamental wrong-code problem: array references didn't
work AT ALL. But it only fixed local variables, not parameters.
2.054 fixed reference parameters. It also completely changed the
treatment of slices.
After this, most of the wrong-code issues with CTFE were fixed. So that
if it compiles in CTFE, it actually works.
2.054 also added support for pointers and heap-allocated structs.
This means that CTFE works in enough cases that a large chunk of Phobos
should actually work now, and also means that most improvements to
Phobos functions shouldn't cause CTFE to fail.
My plan is that 2.055 will clean up the smaller issues, which are of two
types: (1) special cases that were overlooked (hopefully all of these
will cause internal compiler errors rather than wrong-code); and (2) the
compiler runtime helper functions.
This will leave the CTFE rules as:
(1) source code must be available;
(2) no access to global or static variables;
(3) no asm;
(4) no classes (and therefore, no interfaces, can't throw exceptions, etc);
(5) no closures.
(4) and (5) are only temporary limitations.
Note that for any function which is pure, we can expect that
non-CTFEable regressions will happen only when external functions are
called. Interestingly this is something which could be checked statically.
(CTFE can also use functions which aren't pure, but they're considerably
more difficult to check, since they are CTFE-callable only for
particular combinations of parameters).
