[dmd-beta] Fighting with 2.059 and not quite winning

[Jonathan M Davis]

On Saturday, April 07, 2012 06:51:53 Vladimir Panteleev wrote:
> On Sat, 07 Apr 2012 03:25:17 +0300, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> > So, I don't know why you're having problems.
> 
> Sorry, I should have made this clear:
> 
> The issue isn't with toString, but toHash.
> 
> The reason this affects me is that both toString and toHash use a common
> code path, so the called functions' attributes have to follow the lowest
> common denominator - as set by toHash.

Ah. So it has to do with something specific that you're doing. I know that 
there was an issue with getHash:

http://d.puremagic.com/issues/show_bug.cgi?id=7826

I don't know if the fix for that helps you or not. Honestly, I never would have 
thought that anyone would have toHash and toString using common code paths, 
since they do completely different things, but there's certainly nothing 
stopping you (aside from the purity issues and whatnot). But given that 
there's not a dependency on toString or conversions to string of any kind in 
toHash in the general case, I don't think that it's any surprise that wasn't 
taken into account in making toHash require purity.

My _guess_ as to why toHash now requires purity is because the current AA 
implementation relies on it as part of the transition to proper constness and 
purity in Object and whatnot (the implementation isn't currently templated, so 
it can't take advantage of purity inference).

I don't know that this issue would hold up the release, but I'll try and take 
a stab at the purity issues in to!string this weekend and see how close we are 
to make that work. If we're close, it may be possible and reasonable to get it 
into the next release, but if there are a bunch of changes required, then 
probably not. It _does_ not get done relatively soon though (and probably by 
2.060, because we're probably going to work on toString in Object being const 
correct with that release).

_Worst_ case, you can use casts to get around the problem. std.datetime now 
does that with LocalTime and UTC's opCall functions in order to lazily 
initialize their singletons. So, it's quite possible. Ideally, you wouldn't 
have to do that though.

- Jonathan M Davis