toHash => pure, nothrow, const, @safe

[Alex Rønne Petersen]

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