On 12/03/12 00:55, Alex Rønne Petersen wrote:
On 12-03-2012 00:54, 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
A 2. it's just plain annoying to annotate them
Maybe we need @nice or something, to mean pure nothrow @safe.
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
That was sounding reasonable, but...
@safe (if not already marked as @trusted).
...this part is a bit scary. It sounds as though the semantics are a bit
fuzzy.
There is no way to make a function as 'impure' or 'does_throw'.
But you can annotate with @system.
It may be a hack, but you know, those have special semantics/meanings in
the first place, so is it really that bad?
Agreed, they are in some sense virtual functions. But how would you
declare those functions. With "pure nothrow @safe", or with "pure
nothrow @trusted" ?
Consider also that contract
blocks are now implicitly const, etc.
But the clutter problem isn't restricted to those specific functions.
One issue with pure, nothrow is that they have no inverse, so you cannot
simply write pure: nothrow: at the top of the file and use 'pure
nothrow' by default.
The underlying problem is that, when spelt out in full, those
annotations uglify the code.
