Against enforce()

[Steven Schveighoffer]

On Fri, 18 Mar 2011 20:06:16 -0400, Don <nospam at nospam.com> wrote:

> Steven Schveighoffer wrote:
>> On Fri, 18 Mar 2011 14:35:27 -0400, Don <nospam at nospam.com> wrote:
>>
>>> Steven Schveighoffer wrote:
>>>> On Fri, 18 Mar 2011 04:34:54 -0400, Don <nospam at nospam.com> wrote:
>>>>
>>>>>> Steven Schveighoffer Wrote:
>>>>>>
>>>>>>> As long as the delegate does not access shared/global data, it  
>>>>>>> should be  able to be pure.  Even delegates which modify TLS data  
>>>>>>> should be able to  be pure (weak-pure, but still pure).
>>>>>
>>>>> TLS variables are global and must not be accessed from any function  
>>>>> marked as pure. With regard to purity, there isn't any difference  
>>>>> between shared and TLS variables.
>>>>  However, it's still not shared.
>>>>  This, for example, is a weak pure function:
>>>>  void foo(int *n) pure { *n = 5;}
>>>>  Because TLS variables are not shared, you should be able to do this:
>>>>  int x;
>>>>  void bar()
>>>> {
>>>>   foo(&x);
>>>> }
>>>
>>> Yes, that compiles fine. But bar() is not pure.
>>>
>>>>  But you are right, there is a huge difference between a local  
>>>> reference to TLS data and directly accessing TLS data -- the latter  
>>>> can be obscured from the compiler, resulting in the compiler thinking  
>>>> the function can be strong pure.
>>>>  So I don't know exactly how to mitigate this, but in my mind, it  
>>>> feels like this should work:
>>>>  int foo(bool cond, lazy int n) pure { if(cond) return n; return 0;}
>>>>  int x;
>>>>  void bar()
>>>> {
>>>>    foo(x == 4, x = 5);
>>>> }
>>>>  It seems not too different from the above example where you pass the  
>>>> address of x.  But obviously the x = 5 delegate cannot be pure (it  
>>>> modifies TLS data).
>>>>  We may have no recourse to get this to work.  It may be a lost  
>>>> cause, and you just can't have lazy variables for pure functions.
>>>
>>> It's not a lost cause, it's a two-liner!
>>> mtype.c line 5045:
>>>
>>>                  if (fparam->storageClass & STClazy)
>>>                  {
>>> -                    error(0, "cannot have lazy parameters to a pure  
>>> function");
>>> +                    tf->purity = PUREweak;
>>> +                    break;
>>>                  }
>>>
>>> This is a bit conservative: it would be possible to allow lazy  
>>> parameters to be marked as pure, which would allow them to be strongly  
>>> pure. But that would probably not be worth the extra complexity.
>>  I'm not sure this works.  Aren't you allowed to pass in a delegate to  
>> a lazy parameter?
>
> Yes.
>
>>  For example:
>>  shared int x;
>>  int foo()
>> {
>>    return x;
>> }
>>  int bar(lazy int n) pure
>> {
>>    return n;
>> }
>>  void baz()
>> {
>>    bar(&foo);
>> }
>>  or alternatively:
>>  void baz()
>> {
>>    bar(x);
>> }
>
> This compiles just fine. (Well, you need to use bar(foo) not bar(&foo)).
> But if you try to mark baz() as pure, here's what you get:
>
> test0.d(135): Error: pure function 'baz' cannot call impure function  
> 'foo'

But does this make sense?  A pure function (bar) is reading a shared  
integer via foo, I thought that was a big no-no?

> or for the second case:
>
> test0.d(136): Error: pure function 'baz' cannot access mutable static  
> data 'x'
>
> bar is just weakly pure.

But I wasn't saying baz is pure, I was saying bar is pure (probably should  
be more diverse in the names).  But I'm concerned about a pure function  
being able to indirectly read/write shared data.  Does this make sense?  I  
guess a weak-pure function acts like a normal function when called from a  
normal-function.  Is that why it's ok?  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!)?

So is the rule that if you pass a non-pure delegate into a pure function  
it's automatically weak-pure?  If so, does this not mean we need two  
versions of pure functions that take delegates, one that takes a pure  
delegate, and one that takes a non-pure one?  Otherwise, how do you know  
what's strong and what's weak?  For example, a weak pure function is  
strong when called from a strong-pure function, so you could say if the  
calling function is pure, the call is strong-pure.  But wouldn't you need  
separate generated code for the two cases?

I guess you can see from the number of question marks, I'm not sure about  
this at all, either way :)  If you think it will work, then I trust your  
judgment.

-Steve