Proposal: Relax rules for 'pure'

[Robert Jacques]

On Wed, 22 Sep 2010 07:54:26 -0400, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2010-09-22 01:26:01 -0400, "Robert Jacques" <sandford at 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.