On Sun, 11 Mar 2012 19:54:09 -0400, Walter Bright
<newshou...@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
