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. Or, as a compromise, perhaps the compiler can auto-infer most of the attributes without any further effort from the user. T -- If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher
