For all intents and purposes, the following code can be weakly pure:

struct VAO
{

}

On Friday, 18 July 2014 at 14:15:46 UTC, Rene Zwanenburg wrote:
> For all intents and purposes, the following code can be weakly pure:
>
> struct VAO
> {
>
> }

urrmm. Did you mean to post more than that?

On Friday, 18 July 2014 at 15:57:40 UTC, John Colvin wrote:
> On Friday, 18 July 2014 at 14:15:46 UTC, Rene Zwanenburg wrote:
>> For all intents and purposes, the following code can be weakly pure:
>>
>> struct VAO
>> {
>>
>> }
>
> urrmm. Did you mean to post more than that?

Haha yup. Not sure what happened there.

I'm a bit short on time at the moment, but what it comes down to is that Derelict loads functions from DLL's and assigns them to global function pointers. Of course, these function pointers have to be mutable.

Is there a nice way to call such functions from a pure function?

On Friday, 18 July 2014 at 16:12:18 UTC, Rene Zwanenburg wrote:
> On Friday, 18 July 2014 at 15:57:40 UTC, John Colvin wrote:
>> On Friday, 18 July 2014 at 14:15:46 UTC, Rene Zwanenburg wrote:
>>> For all intents and purposes, the following code can be weakly pure:
>>>
>>> struct VAO
>>> {
>>>
>>> }
>>
>> urrmm. Did you mean to post more than that?
>
> Haha yup. Not sure what happened there.
>
> I'm a bit short on time at the moment, but what it comes down to is that Derelict loads functions from DLL's and assigns them to global function pointers. Of course, these function pointers have to be mutable.
>
> Is there a nice way to call such functions from a pure function?

I haven't tried it, but can you cast the function references to be pure?

On Friday, 18 July 2014 at 16:19:20 UTC, John Colvin wrote:
> On Friday, 18 July 2014 at 16:12:18 UTC, Rene Zwanenburg wrote:
>> On Friday, 18 July 2014 at 15:57:40 UTC, John Colvin wrote:
>>> On Friday, 18 July 2014 at 14:15:46 UTC, Rene Zwanenburg wrote:
>>>> For all intents and purposes, the following code can be weakly pure:
>>>>
>>>> struct VAO
>>>> {
>>>>
>>>> }
>>>
>>> urrmm. Did you mean to post more than that?
>>
>> Haha yup. Not sure what happened there.
>>
>> I'm a bit short on time at the moment, but what it comes down to is that Derelict loads functions from DLL's and assigns them to global function pointers. Of course, these function pointers have to be mutable.
>>
>> Is there a nice way to call such functions from a pure function?
>
> I haven't tried it, but can you cast the function references to be pure?

Casting to pure would break purity if the called function is not actually pure. AFAIU, the problem is that the mutable function pointers are not accessible from inside the pure function at all, in which case the solution is to cast them to immutable, not to pure.

But to cast something, you'd need to have access to it in the first place...

This seems to work:

    int function(int) pure my_func_ptr;

    struct CallImmutable {
        static opDispatch(string fn, Args...)(Args args) {
            return mixin(fn)(args);
        }
    }

    int test() pure {
        return CallImmutable.my_func_ptr(1);
    }

But I suspect it's because of a bug. `CallImmutable.opDispatch` should not be deduced to be pure, and this not be callable from `test`.

It's ok to deduce opDispatch as pure, but then its purity should be enforced and error reported.

On 07/19/2014 03:53 PM, Kagamin wrote:
> It's ok to deduce opDispatch as pure, but then its purity should be
> enforced and error reported.

Why would it be ok to deduce opDispatch as pure only to report an error that it is not actually pure? This would be a bug as well (albeit none that causes unsoundness.)

Broken purity deduction is less critical than broken purity check. We can hit the latter somewhere else.

On Saturday, 19 July 2014 at 11:12:00 UTC, Marc Schütz wrote:
> Casting to pure would break purity if the called function is not actually pure. AFAIU, the problem is that the mutable function pointers are not accessible from inside the pure function at all, in which case the solution is to cast them to immutable, not to pure.

Indeed that is the problem. I didn't think of casting to immutable, that should work..

>
> But to cast something, you'd need to have access to it in the first place...
>
> This seems to work:
>
>     int function(int) pure my_func_ptr;
>
>     struct CallImmutable {
>         static opDispatch(string fn, Args...)(Args args) {
>             return mixin(fn)(args);
>         }
>     }
>
>     int test() pure {
>         return CallImmutable.my_func_ptr(1);
>     }
>
> But I suspect it's because of a bug. `CallImmutable.opDispatch` should not be deduced to be pure, and this not be callable from `test`.

Yeah that looks like a bug. I should be able to conjure something up, perhaps using assumeUnique, that won't break in newer versions.

Thanks for the answers!

On Tuesday, 22 July 2014 at 13:35:27 UTC, Rene Zwanenburg wrote:
> On Saturday, 19 July 2014 at 11:12:00 UTC, Marc Schütz wrote:
>> Casting to pure would break purity if the called function is not actually pure. AFAIU, the problem is that the mutable function pointers are not accessible from inside the pure function at all, in which case the solution is to cast them to immutable, not to pure.
>
> Indeed that is the problem. I didn't think of casting to immutable, that should work..
>
>>
>> But to cast something, you'd need to have access to it in the first place...
>>
>> This seems to work:
>>
>>    int function(int) pure my_func_ptr;
>>
>>    struct CallImmutable {
>>        static opDispatch(string fn, Args...)(Args args) {
>>            return mixin(fn)(args);
>>        }
>>    }
>>
>>    int test() pure {
>>        return CallImmutable.my_func_ptr(1);
>>    }
>>
>> But I suspect it's because of a bug. `CallImmutable.opDispatch` should not be deduced to be pure, and this not be callable from `test`.
>
> Yeah that looks like a bug. I should be able to conjure something up, perhaps using assumeUnique, that won't break in newer versions.
>
> Thanks for the answers!

Filed as:
https://issues.dlang.org/show_bug.cgi?id=13187