toHash => pure, nothrow, const, @safe

[Don Clugston]

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.