Discussion Thread: DIP 1032--Function pointers and Delegate Parameters...--Community Review Round 1

Steven Schveighoffer schveiguy at gmail.com
Sat Apr 11 20:25:28 UTC 2020


On 4/10/20 8:05 PM, Walter Bright wrote:
> On 4/10/2020 5:22 AM, Steven Schveighoffer wrote:
>> No, you don't "make" foo pure, it is specifically marked pure.
>>
>> In other words, you have:
>>
>> void foo(void delegate() @called) pure @nogc @safe { dg(); }
>>
>> So the @called attribute says "foo calls dg", which means that for a 
>> specific call of foo, you can strip off attributes that it doesn't have.
> 
> Sorry, that's still another way of saying the same thing

I meant that the compiler doesn't check for purity in the surrounding 
code *based on the call*, it's already checked *when it is compiled*:

To drive the point home:

--- a.di
module a;
void foo(void function() @called fn) pure;
---
module b;
import a;

void bar1() pure {}
void bar2() {} // not pure

void fun1() pure
{
    foo(&bar1); // OK
    // foo(&bar2); // Error, cannot call impure foo
}

void fun2()
{
    foo(&bar1); // OK, can call pure from impure function
    foo(&bar2); // also OK, foo now becomes impure.
}
---

Note that the implementation of foo isn't relevant. Everything OTHER 
THAN the function pointer call is checked for purity, because it's 
marked pure. If the non-function pointer call code is not pure, it won't 
compile. No new situations can happen because it's already done compiling.

> foo()'s 
> implementation has to be pure-compatible. This is impractical for 
> reasons mentioned.

foo()'s implementation is pure compatible, because the compiler checked 
it. What is difficult or impractical about this? We already do this 
today -- you mark a function pure, the compiler verifies that it is.

I don't know what you mean by "impractical" or "reasons mentioned". 
Nothing in our previous dialog points to you understanding this 
proposal. In particular this comment:

> This is just not going to work if foo() does much more than just call the delegate.

reads like you think the compiler is incapable of checking for purity, 
which I know you don't think that.

If you want to present an argument against this, one such "because I 
don't like it" is perfectly fine. After all, you are the one deciding 
the result. If you want to show objectively that it's not workable or 
inferior, more words than "reasons mentioned" are needed. What reasons? 
Where are they mentioned?

-Steve


More information about the Digitalmars-d mailing list