Le 18/06/2012 17:23, Timon Gehr a écrit :
On 06/18/2012 05:13 PM, deadalnix wrote:
Le 18/06/2012 16:55, Mehrdad a écrit :
On Monday, 18 June 2012 at 14:48:37 UTC, deadalnix wrote:
Le 18/06/2012 16:44, Mehrdad a écrit :
Interesting, making the delegate `pure' doesn't change anything
either.
So 'pure' doesn't let you "infer something just by looking at the code
either", right?
It does ! It tell you that the function have no side effect, and that
the function called with identical arguments will return identical
results.
pure will not ensure constness or immutability. const and immutable
are made for that.
The fact that D decouple purity and immutability is a very nice design
decision and is explained nicely here :
http://klickverbot.at/blog/2012/05/purity-in-d/
Identical calls giving identical results? What?
import std.stdio;
struct S
{
this(int a)
{
this.a = a;
this.increment = { return this.a++; };
}
int a;
int delegate() pure increment;
auto oops() const { return this.increment(); }
}
void main()
{
auto c = immutable(S)(0);
writeln(c.oops()); // 0
writeln(c.oops()); // 1
writeln(c.oops()); // 2
writeln(c.oops()); // 3
writeln(c.oops()); // 4
writeln(c.oops()); // 5
}
They are not call with the same parameters. The hidden parameter have
changed (I know this is tricky).
The whole problem is that the hidden parameter has changed. It is
immutable!
As said, this is effectively a const/immutable issue. Not a purity issue.
I'm not claiming that this code is fine, just explaining that the code
is fine in regard to purity.
