Cannot compare object.opEquals is not nogc

Rufus Smith via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Sat Jul 23 14:33:29 PDT 2016


On Saturday, 23 July 2016 at 17:23:37 UTC, Marco Leise wrote:
> Am Sat, 23 Jul 2016 13:18:03 +0000
> schrieb Rufus Smith <RufusSmith at indi.com>:
>
>> Trying to compare a *ptr value with a value in nogc code 
>> results in the error:
>> 
>> Error: @nogc function '...' cannot call non- at nogc function
>> 'object.opEquals'
>> 
>> Shouldn't object opEquals be marked?
>
> The only situation that you can work around is if the 'object' 
> is actually known to be one of your @nogc objects. Then you can 
> simply downcast before calling opEquals.
>
> It's certainly limiting, but just an artifact of OOP and I can 
> assure you that making D usable without GC has been high on the 
> priority list (for an community driven open-source project 
> anyways). Phobos got reworked to get rid of unnecessary GC 
> allocations and Andrei Alexandrescu contemplated making 
> object's methods @nogc at one point.
>
> If you need a restricted object hierarchy, you'll have to write 
> a new "NoGcObject" base class. opEquals would still take 
> "object", though you can avoid a dynamic cast by writing:
>
>   (cast(NoGcObject)cast(void*)obj).someMethod();
>
> The cast to void* prior to the downcast drops the class type 
> information and a dynamic cast becomes a static cast.

I am trying to write some general code that works on arbitrary 
types. I need to compare, obviously, as that is relatively basic 
thing on objects.

About the only half-ass solution I can think of is to use 
introspection and require the type to support a nogc version of 
Equals. Of course, this only passes the buck.

The problem is, D was designed with GC in mind, which was flawed 
from the get go and now trying to undo the tangled mess leads to 
"We can't do that because it's not backwards compatible".  So one 
crack leads to another to another. From what I gather, this isn't 
just a problem with nogc but many "after the fact enhancements" 
that don't work the way they should because of lack of foresight 
on the designers of D.









More information about the Digitalmars-d-learn mailing list