toHash => pure, nothrow, const, @safe

[Jonathan M Davis]

On Monday, March 12, 2012 14:23:28 Alex Rønne Petersen wrote:
> On 12-03-2012 14:16, deadalnix wrote:
> > Le 12/03/2012 13:51, Alex Rønne Petersen a écrit :
> >> On 12-03-2012 10:40, Walter Bright wrote:
> >>> On 3/12/2012 1:08 AM, Martin Nowak wrote:
> >>>> What's wrong with auto-inference. Inferred attributes are only
> >>>> strengthening
> >>>> guarantees.
> >>> 
> >>> Auto-inference is currently done for lambdas and template functions -
> >>> why? - because the function's implementation is guaranteed to be visible
> >>> to the compiler. For other functions, not so, and so the attributes must
> >>> be part of the function signature.
> >> 
> >> Isn't auto-inference for templates a Bad Thing (TM) since it may give
> >> API guarantees that you can end up silently breaking?
> > 
> > As long as you can explicitly specify that too, and that you get a
> > compile time error when you fail to provide what is explicitly stated,
> > this isn't a problem.
> 
> But people might be relying on your API that just so happens to be pure,
> but then suddenly isn't!

True, but without out, pure, @safe, and nothrow are essentially useless with 
templates, because far too many templates depend on their arguments for 
whether they can be pure, @safe, and/or nothrow or not. It's attribute 
inference for templates that made it possible to use something stuff like 
std.range and std.algorithm in pure functions. Without that, it couldn't be 
done (at least not without some nasty casting). Attribute inference is 
necessary for templates.

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.

In both cases, I believe that the best solution that we have is to unit test 
stuff to show that it _can_ be pure, @safe, nothrow, and/or CTFEable if the 
arguments support it, and then those tests can guarantee that it stays that 
way in spite of any code changes, since they'll fail if the changes break 
that.

- Jonathan M Davis