Against enforce()

[Don]

Steven Schveighoffer wrote:
> 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;}

No.

> 
> I was under the impression that a pure function couldn't access shared 
> data -- period.  Is this not true?  

Not necessarily. It only guarantees that it won't access shared data 
unless you provided it.

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

It will only be callable from a strong-pure function if (a) the delegate 
is marked as pure; or (b) it's a delegate literal (so its purity can be 
checked).
Lazy is an instance of (b).

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

If the delegate isn't pure, it cannot be called at all from a strongly 
pure function.
Pure functions (even weakly pure) cannot call non-pure delegates in any 
way -- except in the aforementioned delegate literal case.

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