Against enforce()

[Steven Schveighoffer]

On Mon, 21 Mar 2011 10:08:56 -0400, Don <nospam at nospam.com> wrote:

> Steven Schveighoffer wrote:

>> Will there not be an expectation that a pure function will not  
>> read/write shared data that will be broken (i.e. why did the compiler  
>> allow this, I thought I was safe from this!)?
>
> If you pass the address of global or shared data into a weakly pure  
> function, it won't be pure. If you have a function with a strongly pure  
> signature, global data can never be passed to it.

Just on this one point, TLS or __gshared references are indistinguishable  
 from normal references, but shared references are not the same, the type  
system lets you know it's shared.  I thought this was the main reason why  
we were allowed to create weak-pure functions, because d has this  
distinction.  Are you allowed to declare a function like this?

int foo(shared int *x) pure {return *x;}

I was under the impression that a pure function couldn't access shared  
data -- period.  Is this not true?  Clearly, this theoretically weak-pure  
function could not be called from a strong-pure function, so the pure  
decoration is useless.

But this is very similar to a delegate that does the same thing.

Why does one make sense and the other not?  In other words, if I have a  
function like this:

int foo(int delegate() x) pure {...}

is this *ever* callable from a strong-pure function?  Or does the delegate  
have to be declared pure?  It seems to me that either:

1) it's not ever callable from a strong-pure function, making the pure  
decoration useless or
2) it's callable from a strong pure function, but then the compiler needs  
to generate two copies of the function, one with a pure delegate, one  
without.

On item 2, the reason I feel this way is in the case where foo wants to  
pass the delegate to another pure function, it might optimize that call  
differently if the delegate is known to be pure.  Or maybe we don't/can't  
care...

Thanks for having patience, I'm asking all these questions because I want  
to make sure we do not put in rules that are wrong but hard to remove  
later when everything uses them -- even though I don't understand  
everything going on here ;)

-Steve