<@U0JN7HPQQ> Hello! I'm working on <KT-18435>, and...

# kontributors

[Iaroslav Postovalov]

@mglukhikh Hello! I'm working on KT-18435, and I've started implementing it as an IR lowering phase for == calls. My problem is that IrClass doesn't have sealedSubclasses . I see only two options to solve this problem:
1. Publish IrBuiltIns.toIrSymbol function to use ClassDescriptor.getSealedSubclasses (and it seems to be a bad way).
2. Add such property and support it in fir2ir and psi2ir.
I need some opinions from the compiler team to get if I can add this property or this problem can be solved in another way.

[Iaroslav Postovalov]

cc @Ilmir Usmanov [JB]

[dmitriy.novozhilov]

cc @udalov

[dmitriy.novozhilov]

Option 1 is definitely bad, because we want to get rid of descriptors from IR at all. Option 2 looks ok from frontend perspective, but I think we need to hear opinion from someone from backend teams

[Ilmir Usmanov [JB]]

cc @dmitry.petrov for psi2ir expertise.

[Iaroslav Postovalov]

😭

[udalov]

Can you clarify how exactly you are going to fix this issue, i.e. how you’d use sealedSubclasses here?

[udalov]

Adding IrClass.sealedSubclasses should be OK but it might be an overkill for KT-18435 which is basically a minor performance optimization.

[Iaroslav Postovalov]

Let us have a sealed class or interface.
If in == the left operand is an instance of that class and the right one is an object instance, moreover no subtypes of our sealed class

[Iaroslav Postovalov]

override equals , then we can replace == with === .

[Iaroslav Postovalov]

So, I need sealedSubclasses to check whether any of subtypes has custom equals .

[Iaroslav Postovalov]

@udalov

[udalov]

moreover no subtypes of our sealed class override equals

Note that this won’t work out of the box in terms of partial/incremental compilation. You can only safely assume anything like that about declarations in the source files that you’re compiling. If the sealed class is in another module, or even in the same module but compiled on a previous round of incremental compilation, you can’t rely that there’s no custom equals in its hierarchy. Because it might be added or removed independently from the use site code, which will change runtime behavior.

It’s not directly related to your question, I’m just trying to process if this optimization would be worth it at all. So far it looks like it needs to be implemented very carefully: even if you have IrClass.sealedSubclasses, you need to check that all of them are declared in a source file, and you need a separate change in incremental compilation machinery to make sure that once a user adds equals to a hierarchy, all call sites that use == are invalidated. And the latter seems rather complicated for a minor performance optimization.

[udalov]

@dmitry.petrov has been pinged above, I’d also wait for his take on this issue. :)

[Iaroslav Postovalov]

Well, there aren't so many up-for-grabs issues, so I think this one is OK

[dmitry.petrov]

From the first glance, optimization you are trying to implement actually looks dangerous in the scope of separate compilation. A class, sealed or not, might get a user-defined equals method later. Replacing equality with reference equality thus would change the behavior here.
The fact that the given class is sealed doesn't seem to be relevant.

[dmitry.petrov]

So, strictly speaking, it has nothing to do with a class on the left side of equality being sealed, or when being sealed.
Class should belong to the same module and should have no user-defined equals (should have equals inherited from Any).

[Iaroslav Postovalov]

I know, my current code which optimizes Object == something already checks it.

[Iaroslav Postovalov]

The "sealedness" of class is important because if left operand isn't sealed, it is undefined whether it has user-defined equals

[Iaroslav Postovalov]

cc @snrostov in the context of incremental compilation

[dmitry.petrov]

The "sealedness" of class is important because if left operand isn't sealed, it is undefined whether it has user-defined equals

No. Both sealed and non-sealed classes can have user-defined equals.
It's important whether we can definitely say that the class of the left operand doesn't have a user-defined equals.
It also should belong to the same module (so that it would be recompiled together with the given code).
Otherwise we can't replace object equality with reference equality.

It's a frequent misconception that sealed classes are true algebraic data types. Unfortunately, they are not (even though it's a good idea to implement an algebraic data type using a sealed class), because of possibility of user-defined equals. Such user-defined equals can do whatever it wants, because it can.

[Iaroslav Postovalov]

In case of sealed classes we can just check all the subclasses of it, can't we?