Purity in Java & D

[Simen kjaeraas]

Walter Bright <newshound2 at digitalmars.com> wrote:

> Jonathan M Davis wrote:
>> Having the compiler determine purity would be cool, but it runs into a  
>> few of problems.
>
> The most serious one I can think of is:
>
> Suppose you are depending on a function being pure. If the compiler  
> determines its purity, it *does not tell you* if it is impure. Your code  
> just doesn't behave as you expect. If you happen to notice that it isn't  
> being treated as pure, you won't know why. It could be the function  
> itself or any of the functions in its transitive call tree.
>
> Basically, anyone working on any function in the call tree could break  
> purity for the whole shebang, and you'd have no idea this was happening.
>
> With D, purity is part of the function signature. That means the  
> compiler does not determine purity, the compiler *checks* purity. That's  
> a fundamental difference. If it isn't pure, you'll immediately know it,  
> and where. If you change a function from pure to impure, any function  
> that calls it will need to be recompiled (or it will fail to link).  
> There won't be any stealth changes subverting the system.

To their defense, the mentioned Java purity system also checks rather than
determines purity (or rather, a function is pure if its signature is all
immutable, no checking needed). Given D's plethora of features, one of
which is mutable global state, such a system is insufficient for our needs.

-- 
Simen