On 7/23/16 10:53 AM, Rufus Smith wrote:
On Saturday, 23 July 2016 at 14:15:03 UTC, Lodovico Giaretta wrote:
On Saturday, 23 July 2016 at 13:18:03 UTC, Rufus Smith wrote:
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?
If object.opEquals is marked @nogc, than all D classes must implement
it as @nogc, because (of course) you cannot override a @nogc method
with a not-@nogc one (while the opposite is possible, of course).
So marking it @nogc is not only a big breaking change, but also very
limiting.
Um, this isn't right. GC code can always call non-gc code.
The issue is that for *classes*, the proper way to add an opEquals is to
override the base version. The base version existed LONG before @nogc
did, and so it's not appropriately marked.
Not only that, but @nogc is too limiting (if I want to use GC in
opEquals, I should be able to).
The real problem here is that there is a base method at all. We have
been striving to remove it at some point, but it is very difficult due
to all the legacy code which is written.
Almost all the Object base methods need to be removed IMO. You can add
them at a higher level if you need them, and then specify your
requirements for derived classes.
Including opHash, opCmp, toString, etc.
If you mark opEquals nogc, it breaks nothing except implementations of
opEquals that use the GC. GC code can still call it nogc opequals, it
only enforces opEquals code to avoid the GC itself, which isn't a
terrible thing.
It breaks all classes which use GC in opEquals. Note that you can't
really compare two immutable or const objects either! (well, actually
you can, but that's because the runtime just casts away const and lets
you have undefined behavior).
What is terrible is that nogc code can never have any equality
comparisons! It is impossible unless one manually tests them, but how?
Every method would be brittle. Do a memory test? compare element by
element? One can't predict what to do.
It is unfortunate. I hope we can fix it. I'd rather not add another
exception like we have for comparing const objects.
So, you are trying off laziness to break nogc. As it stands, if nogc
code can't compare equality, it is broken and useless. Why put it in the
language then?
@nogc is not useless, it just cannot handle Objects at the moment.
Broke! Even if opEquals of T does not use any GC we can't write test to
be nogc, which means we can't have S be nogc or anything that depends on
S that is nogc. This must be a dirty trick played by the implementors of
nogc to keep everyone on the gc nipple?
I assure you, it's not a trick. It's legacy. It needs fixing, but the
fix isn't painless or easy.
-Steve
