[phobos] CTFE Regressions
Jonathan M Davis
jmdavisProg at gmx.com
Sun Mar 20 17:03:28 PDT 2011
> This is a funny issue. They are not regressions against documented
> behaviour. At this stage, using a Phobos function at compile time is
> basically relying on undocumented behaviour --
> although it may happen to work in CTFE, that's just luck. The problem
> is, that this isn't stated strongly enough anywhere.
> In particular, I think we should document that
> *** any Phobos function which is not marked as pure, should not be
> relied on as working in CTFE ***.
> Bear in mind that because of bug 1330, a large fraction of Phobos
> array functions which will compile in CTFE, don't actually work in
> reality.
> We may want to choose a small set of functions which we guarantee will
> work in CTFE, and add tests for them in general as you suggest.
> But the most important issue is that we have to make clear to people
> that using Phobos functions in CTFE is undefined behaviour.
And of course bringing pure into it brings in all of the problems with pure
(we _really_ need conditional purity of some kind if we want the templated
functions in Phobos to work with pure). :)
I have no problem with stating that whether a function works with CTFE in
Phobos is undefined behavior, but it's pretty limiting if you can't CTFE much
in Phobos. Most functions end up relying on Phobos one way or another, and if
you can't rely on Phobos working with CTFE consistently, then CTFE becomes a
_lot_ less useful.
This _does_ strike me as the sort of issue, however, that isn't really ready
to be completely resolved (properly sorting out how Phobos deals with stuff
like const, pure, and nothrow could have a definite effect on how things work
and whether things are CTFE-able). However, I also think that it's something
that we need to think about. And there may indeed be functions which we can
unequivocally say can be used with CTFE and should always be useable with
CTFE. _Those_ are the sort of functions that we should really probably
consider testing for CTFE in the short term.
However, it _is_ an interesting problem overall in that by relying on CTFE,
you're effectively relying on something which is not part of the function
signature, and CTFE was designed from the get-go with the idea that it just
worked without you having to do anything special like use a particular
function attribute or whatnot. So, relying on is arguably bad, but if you
can't rely on it, you can't really use it... So, yeah. This is a funny issue.
I do think that it needs to be considered though.
- Jonathan M Davis
More information about the phobos
mailing list