should pure functions accept/deal with shared data?

[Steven Schveighoffer]

On Wed, 06 Jun 2012 19:01:59 -0400, Alex Rønne Petersen <alex at lycus.org>  
wrote:


> Steven, in your particular case, I don't agree entirely. The operation  
> can be atomic quite trivially by implementing inc() like so (for the  
> shared int case):
>
> void inc(ref shared int i) pure nothrow
> {
>      // just pretend the compiler emitted this
>      asm
>      {
>          mov EDX, i;
>          lock;
>          inc [EDX];
>      }
> }
>
> But I may be misunderstanding you.

I think you are.  I understand the implementation is not correct for  
shared, and that actually is my point.  The current compiler lets you do  
the wrong thing without complaint.  Given that the shared version of the  
function needs to be written differently than the unshared version, we  
gain nothing but bugs by allowing pure functions that operate on shared.

In essence, a pure-accepting-shared (PAS) function is not realistically  
useful from a strong-pure function.  A strong-pure function will have no  
ties to shared data, and while it may be able to create data that could  
potentially be shared, it can't actually share it!  So a PAS function  
being called from a strong-pure function is essentially doing extra work  
(even if it's not implemented, the expectation is it will be some day) for  
no reason.

So since a PAS function cannot usefully be optimized (much better to write  
an unshared version, it's more accurate), and must be written separately  
 from the unshared version, I see no good reason to allow shared in pure  
functions ever.  I think we gain a lot by not allowing it (more sanity for  
one thing!)

-Steve