On Sunday, 24 July 2016 at 15:09:53 UTC, Lodovico Giaretta wrote:
Remember that comparison of complex objects may require
normalization, which may change the objects themselves and
allocate memory.
Sure but this case will be the exception. If an application
really needs this they can implement their own normalizedEquals?
It wouldn't work with the comparison operators, but I don't
really like to use those comparison operators for classes anyway
since they do waaay to much in most cases:
https://github.com/dlang/druntime/blob/master/src/object.d#L136
auto opEquals(Object lhs, Object rhs)
{
// If aliased to the same object or both null => equal
if (lhs is rhs) return true;
// If either is null => non-equal
if (lhs is null || rhs is null) return false;
// If same exact type => one call to method opEquals
if (typeid(lhs) is typeid(rhs) ||
!__ctfe && typeid(lhs).opEquals(typeid(rhs)))
/* CTFE doesn't like typeid much. 'is' works, but
opEquals doesn't
(issue 7147). But CTFE also guarantees that equal
TypeInfos are
always identical. So, no opEquals needed during CTFE.
*/
{
return lhs.opEquals(rhs);
}
// General case => symmetric calls to method opEquals
return lhs.opEquals(rhs) && rhs.opEquals(lhs);
}
...Also, comparisons may throw exceptions that need the GC (see
above). So I'm personally against making those methods @nogc.
Definitely true. One thing to note is that toHash is nothrow.
Whether or not this is too restrictive is definitely up for
debate, but also making opCmp/opEquals nothrow wouldn't be the
worst thing in the world. Of course at this point, it would
likely break ALOT of code, so probably not worth it pragmatically.
But I'm also against a singly-rooted hierarchy. Removing Object
and having multiple class hierarchies would entirely solve the
issue. But please note that you can already "do" that: if you
never use Object, but always subclasses, the fact that Object
isn't @nogc is no longer an issue.
Whoa wait a second...I didn't know you could do this. I thought
everything had to inherit from the object class. Can you share
the syntax to define a class that doesn't derive from object?
P.S.
Talking about throwing exceptions in @nogc is preaching to the
choir :)
https://forum.dlang.org/post/ubtlemuqisxluxfts...@forum.dlang.org
I've explored this issue as well, I came up with a way to throw
exceptions allocated on the NonGC heap, but to clean up memory
the catcher needs to do something to dereference the exception so
it gets cleaned up. There is a DIP for natively supporting
reference counted memory, I don't remember it, but it would allow
such things to be safe to use.
