Proposal: Relax rules for 'pure'

Don nospam at nospam.com
Wed Sep 22 08:44:00 PDT 2010


Robert Jacques wrote:
> 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.

No, you haven't lost that at all. Any function marked as pure still has 
no access to any state, other than what is provided by its parameters. 
It is still thread-safe.

>> 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.

The current pure concept is still included. The syntax for strong pure 
is simply a function declaration with no mutable parameters.
So all existing functions marked 'pure' would remain strong pure.


The one situation where things get more complicated is if you have a 
templated function marked as pure, and you want to ensure that it is 
strong pure.
An isStrongPure!(T) template would need to be written, and used in the 
template constraint.


More information about the Digitalmars-d mailing list