toHash => pure, nothrow, const, @safe

[Alex Rønne Petersen]

On 12-03-2012 06:43, H. S. Teoh wrote:
> 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.

No. Too late in the design process. I have 20k+ lines of code that rely 
on the opposite behavior.

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

No, that has API design issues. You can silently break a guarantee you 
made previously.

>
>
> T
>


-- 
- Alex