toHash => pure, nothrow, const, @safe

[Steven Schveighoffer]

On Sun, 11 Mar 2012 19:54:09 -0400, Walter Bright  
<newshound2 at digitalmars.com> 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
>
> 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).

What about a new attribute @type (or better name?) that means "this  
function is part of the TypeInfo interface, and has an equivalent  
xFuncname in TypeInfo_Struct".  Then it implicitly inherits all the  
attributes of that xFuncname (not necessarily defined by the compiler).

Then, we can have several benefits:

1. This triggers the compiler to complain if we don't correctly define the  
function (as specified in TypeInfo_Struct).  In other words, it allows the  
developer to specify "I want this function to go into TypeInfo".
2. It potentially allows additional interface hooks without compiler  
modification.  For example, you could add xfoo in TypeInfo_Struct, and  
then every struct you define @type foo() would get a hook there.
3. As you wanted, it eliminates having to duplicate all the attributes.

The one large drawback is, you need to annotate all existing functions.   
We could potentially assume that @type is specified on the functions that  
currently enjoy automatic inclusion in the TypeInfo_Struct instance.  I'd  
recommend at some point eliminating this hack though.

-Steve