toHash => pure, nothrow, const, @safe

[H. S. Teoh]

On Sun, Mar 11, 2012 at 04:54:09PM -0700, Walter Bright wrote:
> Consider the toHash() function for struct key types:
> 
> http://dlang.org/hash-map.html
> 
> And of course the others:
> 
> const hash_t toHash();
> const bool opEquals(ref const KeyType s);
> const int opCmp(ref const KeyType s);
> 
> They need to be, as well as const, pure nothrow @safe.
> 
> The problem is:
> 1. a lot of code must be retrofitted
> 2. it's just plain annoying to annotate them

Ah, I see the "just add a new attribute" thing is coming back to bite
you. ;-)


> It's the same problem as for Object.toHash(). That was addressed by
> making those attributes inheritable, but that won't work for struct
> ones.
> 
> So I propose instead a bit of a hack. toHash, opEquals, and opCmp as
> struct members be automatically annotated with pure, nothrow, and
> @safe (if not already marked as @trusted).

I'm wary of the idea of automatically-imposed attributes on a "special"
set of functions... seems a bit arbitrary, and arbitrary things don't
tend to stand the test of time.

OTOH I can see the value of this. Forcing all toHash's to be pure
nothrow @safe makes is much easier to, for example, implement AA's
purely in object_.d (which I'm trying to do :-P). You don't have to
worry about somebody defining a toHash that does strange things. Same
thing with opEquals, etc.. It also lets you freely annotate stuff that
calls these functions as pure, nothrow, @safe, etc., without having to
dig through every function in druntime and phobos to mark all of them.


Here's an alternative (and perhaps totally insane) idea: what if,
instead of needing to mark functions as pure, nothrow, etc., etc., we
ASSUME all functions are pure, nothrow, and @safe unless they're
explicitly declared otherwise? IOW, let all D code be pure, nothrow, and
@safe by default, and if you want non-pure, or throwing code, or unsafe
code, then you annotate the function as impure, throwing, or @system. It
goes along with D's general philosophy of safe-by-default,
unsafe-if-you-want-to.

Or, as a compromise, perhaps the compiler can auto-infer most of the
attributes without any further effort from the user.


T

-- 
If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher