Proposal: Relax rules for 'pure'

[Steven Schveighoffer]

On Wed, 22 Sep 2010 11:55:57 -0400, Robert Jacques <sandford at jhu.edu>  
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 wouldn't be an issue today, but tomorrow large  
> strongly-pure functions will be parallelized automatically in a manner  
> akin to inlining (outlining?). Then it makes a difference. However,  
> these issues feel more like D3 concerns than D2 concerns, particularly  
> when you consider the advantages of making tasks/futures a language  
> level concept.

It's thread safe.  Calling a strongly-pure function concurrently on two  
threads is not multi-threading, it's an optimization.