Discussion Thread: DIP 1042--ProtoObject--Community Review Round 1

[Alexandru Ermicioi]

On Saturday, 15 January 2022 at 13:19:10 UTC, Adam D Ruppe wrote:
> No, there's no compiler hacks, this is a direct consequence of 
> the Liskov substitution principle allowing you to tighten 
> constraints in specializations.
>
> How do you think it works today?

I remember seeing some kind of magic equals function in object.d 
that was used implicitly during equals comparison. Maybe got 
something wrong.
>
>> Anyway, if there is no possibility to make friends inheritance 
>> and method attributes easily, then best is to just remove them 
>> from Object and be done with it.
>
> Not only is there a possibility, it *already works*.
>
> The DIP authors just don't know very much about D's classes.

Yeah narrowing down the method signature is. I just suggested to 
remove opEquals and other operator overloads from Object, and 
provide them as interfaces. Then the devs could choose either to 
make the object equatable and etc. or not.

>> P.S. Can't we enhance compiler and bake the attribute info 
>> into interface itself, and then allow downcasting it to an 
>> interface with specific subset of attribtues?
>> I.e. say we have safe nothrow nogc equals interface. We then 
>> in some random code could downcast safely to safe nogc equals 
>> interface?
>
> Have you tried this?
>
> ```
> interface GcEqual(T) {
>         bool opEquals(T rhs);
> }
>
> interface NoGcEqual(T) {
>         bool opEquals(T rhs) @nogc;
> }
>
> class A : GcEqual!A, NoGcEqual!A {
>         override bool opEquals(Object rhs) {
>                 return this.opEquals(cast(A) rhs);
>         }
>         override bool opEquals(A rhs) @nogc {
>                 if(rhs is null) return false;
>                 return true;
>         }
> }
>
> void main() {
>         A a = new A;
>
>         GcEqual!A g = a;
>         NoGcEqual!A n = a;
> }
> ```

I do know that you can do such thing today. The problem is that, 
the combinations of attributes is huge, and therefore defining 
for each combination an implementation and dedicated interface is 
cumbersome, in cases where code base has various requirements to 
equals comparison for example.

>
> Works today. Restricted functions can implicitly cast to less 
> restricted functions.

Yes, it does. The last suggestion was in order to avoid the huge 
park of interfaces that sprawl.

Say you have a class that implements an interface with equals 
that is nothrow, nogc and safe.

Then you have a function/method that works only with nothrow 
equals, i.e. the parameter type is equals interface with just 
nothrow.
Trying to pass the instance of that class to the function will 
fail, since they are different types.

The idea, was to have only one interface, and the class have 
implemented safe, nothrow, nogc version, and then have the 
compiler, check and allow passing of the object into the method, 
since they are same iface, just that method has relaxed 
constraints. The same should work when you cast interface, i.e. 
having a nothrow nogc interface, you could cast it to same 
interface with just nothrow, and have the runtime guarantee that 
it is possible to do so.
This kind of behavior might solve some problems with attribute 
incompatibility and inheritance.