toHash => pure, nothrow, const, @safe

[Jonathan M Davis]

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.

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.

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