toHash => pure, nothrow, const, @safe

H. S. Teoh hsteoh at quickfur.ath.cx
Mon Mar 12 18:40:34 PDT 2012


On Mon, Mar 12, 2012 at 09:27:41PM -0400, Jonathan M Davis wrote:
> On Tuesday, March 13, 2012 01:15:59 Stewart Gordon wrote:
> > On 11/03/2012 23: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);
> > 
> > <snip>
> > 
> > And what about toString?
> 
> That really should be too, but work is probably going to have to be done to 
> make sure that format and std.conv.to can be pure, since they're pretty much 
> required in most toString functions.

This is not going to be a choice, because some overrides of toHash calls
toString.


> I believe that changes to toUTF8, toUTF16, and toUTF32 were made
> recently which are at least a major step in that direction for
> std.conv.to (since it uses them) and may outright make it so that it
> can be pure now (I'm not sure if anything else is preventing them from
> being pure). But I have no idea what the current state of format is
> with regards to purity, and if the changes to toUTFx weren't enough to
> make std.conv.to pure for strings, then more will need to be done
> there as well.
[...]

Looks like we need a massive one-shot overhaul of almost all of druntime
and a potentially large part of phobos in order to get this
pure/@safe/nothrow thing off the ground.  There are just too many
interdependencies everywhere that there's practically no way to do it
incrementally. I tried the incremental approach several times and have
given up, 'cos every small change inevitably propagates to functions all
over druntime and then some.

And I'm not talking about doing just toHash, or just toString either.
Any of these functions have complex interdependencies with each other,
so it's either fix them ALL, or not at all.


T

-- 
Obviously, some things aren't very obvious.


More information about the Digitalmars-d mailing list