ProtoObject and comparison for equality and ordering

[Jonathan M Davis]

On Wednesday, May 15, 2019 6:40:46 AM MDT Adam D. Ruppe via Digitalmars-d 
wrote:
> On Wednesday, 15 May 2019 at 06:19:19 UTC, Jonathan M Davis wrote:
> > Even an interface is a problem, because then that locks in the
> > attributes.
>
> That's not completely true in general, and only sort of true in
> this specific situation.
>
> In general, attributes are semi-locked, accordance to the Liskov
> substitution principle: you can tighten constraints, but not
> loosen them on child classes.
>
> (Like with current Object, which has no attributes, you are
> allowed to define a child class with `override @nogc @safe
> nothrow` etc. But once you do that, you can never remove them in
> child classes, since then you'd be breaking the promise of the
> parent class' interface)
>
>
> In this specific situation, the attributes are only locked in
> after you define them - which is the same if you did it with or
> without the interface. The interface itself does not demand
> anything unless it specifically lists them.
>
> But, note, they also are not inferred.

Yeah. My point isn't that the exact list of attributes you put on opEquals,
opCmp, etc. is exactly what must be on derived classes. My point is that
once you do or don't put some of those attributes on the function in a base
class, that restricts which attributes can be put on the overrides in
derived classes. The interfaces proposed in Eduard's dconf talk this year
involved making all of the relevant functions @safe const pure nothrow, and
that's a serious problem for any classes that want to do something with
those functions that is incompatible with those attributes. By just letting
user-defined classes define those functions more or less however they want
(like with structs), we make it possible for each class hierarchy to define
them in whatever way is appropriate for that class hierarchy, whereas if we
create an interface, we're restricting what _every_ class can do with
attributes on those functions - which is part of the problem that we have
with Object right now.

> > By templatizing all of the relevant code in druntime
>
> There should be NO code in druntime! All `a < b` is is syntax
> sugar for a method call. It does not need and should not use any
> other function. Just let the compiler rewrite the syntax to the
> call and then do its thing.
>
> The ProtoObject version of __cmp should simply not exist.

That's not true for everything (opEquals specifically has a free function
druntime that calls the opEquals on classes), but what it comes down to in
general is that code that uses opCmp (or any of these functions) in druntime
needs to be templatized rather than being designed to operate on a specific
base class. So, even if opCmp itself doesn't require that code be in
druntime to work, there potentially is relevant code in druntime which would
need to be templatized. Certainly, that's true for opEquals and toHash
because of AAs if nothing else. Regarldess, yeah, ProtoObject shouldn't have
any form of any of these functions on it.

- Jonathan M Davis