On Sunday, 24 July 2016 at 15:09:53 UTC, Lodovico Giaretta wrote:
Yes, making them @nogc would require all existing overrides to
be changed (overrides cannot throw away attributes, but must
specify them explicitly as in the parent class, or stricter).
The real problem making these @nogc is that with the current
state of things @nogc implies nothrow, thus preventing
exceptions (of course we should work to change this thing, and
I'm personally researching convenient ways of doing it; I'll
soon write a post on General about this).
Remember that comparison of complex objects may require
normalization, which may change the objects themselves and
allocate memory. Also, comparisons may throw exceptions that
need the GC (see above). So I'm personally against making those
methods @nogc.
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. While Object (if it exists)
must support any kind of descendant (and thus cannot pose
arbitrary limitations like @nogc is), the roots of
domain-specific hierarchies can exploit the fact that they are
domain-specific to impose meaningful limitations, based on the
expected usage and behaviour, and can thus be @nogc. And you
can either limit your algorithm inputs to objects of a specific
hierarchy or, if you want it generic, use a template (read as:
you don't use Object explicitly, as if it doesn't exists).
Almost off topic but I've recognized a typical error here, I
think that many of us have already seen it too. You develop a
nice class. You put attributes everywhere @safe pure nothrow
@nogc. Yay the unittest pass.
Later you use it for real and you realize then that the
attributes must be removed because you can't do anything in the
overriden methods.
