Uh... destructors?

[Jonathan M Davis]

On Wednesday, February 23, 2011 11:28:01 %u wrote:
> > No. pure is what we want. Changing it would break code and contradict
> > TDPL (though the
> 
> addition of weakly pure isn't in TDPL). Strongly pure functions are
> essentially what you'd expect from pure. Weakly pure functions aren't, but
> they're necessary to make pure very useful, and there's no real benefit in
> using a new keyword or attribute to mark them. pure is the word used
> because we're modeling the idea that multiple calls to the same function
> with the same parameters have the same result - which is indeed the case
> with strongly pure functions. The funny case is weakly pure, but it's
> _not_ optimized out, and it's necessary for pure to be useful. You can
> clearly see whether a function is weakly or strongly pure by looking at
> its signature, so I really don't think that it's an issue.
> 
> 
> You keep on mentioning that weakly pure "is necessary for pure to be
> useful", but the problem is, even if something looks like a duck and walks
> like a duck, that doesn't mean it's a duck! Just because
> __declspec(noalias) _appears_ to mean the same thing as pure from the
> outside perspective that doesn't bother to peek too much into things
> doesn't mean that it's the same thing (it obviously isn't).
> You're mentioning yourself that "weakly pure" isn't in the language
> specs... and if DMD is supposed to be a D compiler, shouldn't it actually
> follow the exact spec? (If "weakly pure" was actually intentional, then
> shouldn't it actually _be_ in the spec? Otherwise, the compiler is clearly
> contradicting TDPL about a fundamental CS concept, isn't it?)

I didn't say anything about the language spec. I said that weakly pure wasn't 
mentioned in TDPL, and I'd have to go read the section on pure in TDPL again to 
see how much of it would need to be changed (possibly very little) for it to be 
correct, even if it doesn't mention weakly pure. Weakly pure was added after 
TDPL was released, so it's not in there. It may very well be in the spec at this 
point. I don't know where the spec is.

Weakly pure was added, because strongly pure functions (which is really all pure 
was originally) quickly become useless, because so few functions can be strongly 
pure, and pure functions can only call pure functions. So, pure was expanded and 
the concept of weakly pure was added. It's still pure though. If you give the 
exact same arguments to a weakly pure function on multiple calls, then the 
results will be exactly the same. It's just that that includes changes to the 
function arguments. As such, those calls can't be optimized out. Strongly pure 
functions, however, do _not_ allow changes to their function arguments, so 
multiple calls to them _can_ be optimized out. All of that is up to the compiler 
(though it's easy enough to tell whether a function is strongly or weakly pure).

You mark a function as pure because its result is the same every time for the 
same arguments. It's up to the compiler whether it can optimize it or not. And 
in cases where the result includes possible changes to the function's arguments, 
the function is weakly pure and can't be optimized by the compiler. But that's 
arguably an implementation detail of the compiler.

pure works just fine, and it _is_ following the academic definition in the sense 
that for the exact same arguments, you get the exact same results every time - 
it's just that the function's arguments are potentially part of that result.

- Jonathan M Davis