Proposal: Relax rules for 'pure'

[Steven Schveighoffer]

On Wed, 22 Sep 2010 15:08:26 -0400, Don <nospam at nospam.com> wrote:

> Robert Jacques wrote:
>> On Wed, 22 Sep 2010 11:44:00 -0400, Don <nospam at nospam.com> wrote:
>>
>>> 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.
>>  No, it isn't. A strongly-pure function is thread safe, but a  
>> weakly-pure function isn't. Since strong/weak is automatically  
>> determined by the compiler, a function's strength can switch due to  
>> long distance code changes.
>
> This is completely incorrect. It can only change strength if its  
> signature changes.

Hypothetical counter-case

struct S
{
    version(stronglypure)
      string s;
    else
      char[] s;
}

pure foo(S s); // changes strength depending on S' contents

-Steve