On Wed, 22 Sep 2010 07:54:26 -0400, Michel Fortin
<michel.for...@michelf.com> wrote:
On 2010-09-22 01:26:01 -0400, "Robert Jacques" <sandf...@jhu.edu> said:
So removing the concurrency safety from pure would greatly expand the
number of pure functions, however, automatic parallelism would be lost.
Don clearly mentioned that this is not lost. Basically, for safe
parallelism what you need is a function that has a) pure and b) no
mutable reference parameter. Both are easily checkable at compile time,
you'd just need to change your test for pure for a test that also checks
the arguments.
What is lost is my ability to declare a function does x in the signature
and for the compiler to check that. I really want to know if code monkey A
changed some type's implementation to be thread unsafe, because detecting
and tracking down a loss of performance due to loss of automatic
parallelism is devilish.
The interesting thing with this change is that you can now call mutators
functions on the local variables inside the pure function, because those
can be made pure. You can't even iterate over a range inside a pure
function without this!
pure int test() {
int result;
auto r = iota(0, 10);
while (!r.empty) {
result += r;
r.popFront(); // can't be pure by current rules!
}
return result;
}
I did mention this benefit in my post, but this example really shows just
how awesome it really is. Which is why I think the concept of a simplified
pure is so powerful and be included in the language. I just want it
included in addition to the current pure concept.
