Non-Purity of Algebraic opEquals

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Fri Sep 18 08:40:07 PDT 2015


On Friday, 18 September 2015 at 13:55:38 UTC, Meta wrote:
> On Friday, 18 September 2015 at 13:53:52 UTC, Nordlöw wrote:
>> On Friday, 18 September 2015 at 13:22:14 UTC, Nordlöw wrote:
>>> Ideas anyone?
>>
>> I tried tagging up `VariantN` with pure until I got to
>>
>>     @property inout(T)* peek(T)() inout pure
>>     {
>>         static if (!is(T == void))
>>             static assert(allowed!(T), "Cannot store a " ~ 
>> T.stringof
>>                     ~ " in a " ~ VariantN.stringof);
>>         if (type != typeid(T))
>>             return null;
>>         static if (T.sizeof <= size)
>>             return cast(inout T*)&store;
>>         else
>>             return *cast(inout T**)&store;
>>     }
>>
>> which then errors as
>>
>> variant.d(701,13): Error: pure function 
>> 'std.variant.VariantN!32LU.VariantN.peek!void.peek' cannot 
>> call impure function 'object.opEquals'
>>
>> for the line
>>
>>     if (type != typeid(T))
>>
>> Why is `object.opEquals` not pure?
>
> It's a long story, but it boils down to the simple fact that 
> nobody's gotten around to it yet. I think the plan was to make 
> it templated, but Jonathan Davis knows more about it than 
> anyone.

The plan is to remove it from Object and templatize the free 
function opEquals which calls opEquals on classes: 
https://issues.dlang.org/show_bug.cgi?id=9769

Last time I tried to templatize it, compiler bugs got in the way. 
I need to make another go at it and see what the current status 
is. But there's a lot of work that has to be done beyond that to 
actually be able remove the various virtual functions from Object.

Regardless, VariantN couldn't have its opEquals explicitly marked 
with pure, because it's a template and needs to work with types 
that don't have a pure opEquals. But it _should_ be able to be 
inferred as pure if the types in question have pure opEquals. 
However, the situation with Object continues to haunt us.

- Jonathan M Davis


More information about the Digitalmars-d mailing list