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 <rufussm...@indi.com>:
Trying to compare a *ptr value with a value in nogc code
results in the error:
Error: @nogc function '...' cannot call non-@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.
