On 12-03-2012 18:55, Jonathan M Davis wrote:
On Monday, March 12, 2012 18:44:06 Alex Rønne Petersen wrote:
Now, that _does_ introduce the possibility of a template being to be pure
and then not being able to be pure thanks to a change that's made to it
or something that it uses, and that makes impossible for any code using
it to be pure. CTFE has the same problem. It's fairly easy to have a
function which is CTFEable cease to be CTFEable thanks to a change to it,
and no one notices. We've had issues with this in the past.
That could be solved with a @ctfe attribute or something, no? Like, if
the function has @ctfe, go through all possible CTFE paths (excluding
!__ctfe paths of course) and make sure they are CTFEable.
1. That goes completely against how CTFE was designed in that part of the idea
was that you _wouldn't_ have to annotate it.
Though, rarely, functions written with runtime execution in mind
actually Just Work in CTFE. You usually have to change code or
special-case things for it to work.
In my experience, anyway...
2. I don't really know how feasible that would be. At minimum, the fact that
CTFE works with classes now would probably render it completely infeasible for
classes, since they're polymorphic, and the compiler can't possibly know all
of the possible types that could be passed to the function. Templates would
screw it over too for the exact same reasons that they can have issues with
pure, @safe, and nothrow. It may or may not be feasible without classes or
templates being involved.
I hadn't thought of classes at all. In practice, it's impossible then.
So, no, I don't think that @ctfe would really work. And while I agree that the
situation isn't exactly ideal, I don't really see a way around it. Unit tests
_do_ catch it for you though. The only thing that they can't catch is whether
the template is going to be pure, nothrow, @safe, and/or CTFEable with _your_
arguments to it, but as long as it's pure, nothrow, @safe, and/or CTFEable
with _a_ set of arguments, it will generally be the fault of the arguments
when such a function fails to be pure, nothrow, @safe, and/or CTFEable as
expected. If the unit tests don't hit all of the possible static if-else
blocks and all of the possible code paths for CTFE, it could still be a
problem, but that just means that the unit tests aren't thorough enough, and
more thorough unit tests will fix the problem, as tedious as it may be to do
that.
- Jonathan M Davis
--
- Alex
