More specific equals operator

[serras]

This is the discussion related to the more specific equals operator proposal. The current full text of the proposal can be found here.

We propose a way to override the equals function from Any with a more specific type, which in turn unlock additional use site diagnostics. This proposal respects the current compilation strategy for equals.

[rnett]

This looks great, I've hit this several times and it's always annoyingly hard to spot.

My only question is around the "like overriding but not actually overriding" behavior:

Must have a single parameter whose type must satisfy:
Being equal or a superclassifier of the classifier defining it,
Being equal or a subclassifier of the declared equality bound of every parent classifier,
Not having a default value

Must not have the override modifier (even if it always actually overrides),

The first one sounds a lot like the restrictions on overriding a method. This is especially true since type-safe equals operators do essentially override any from their supertypes, just without the override keyword. This is confusing, especially for those who are new to the language.

Why is override forbidden on the type-safe equals operators? Is it just to avoid conflicting with the non-type-safe equals? Could that be handled by the compiler instead? Or by just using a different name?

[CLOVIS-AI]

I would be in favor of having the override keyword present when the equals operator is present in a supertype.

class Foo {

    // no 'override' because there is no explicit equals in the supertypes
    operator fun equals(other: Foo) = …
}

interface Foo {
 
    operator fun equals(other: Foo)
}

class FooImpl {

    override operator fun equals(other: Foo) = …
}

I think this is more consistent with the existing language. For example, the IDE should include this method in the 'implement overrides' tooltip, etc.

[serras]

Note that this is equivalent to requiring override on every operator equals, since you're always overriding something (at the very least the one from Any, since that is already an operator).

[CLOVIS-AI]

In Kotlin, overriding with different parameters is not allowed, though. So:

interface Foo {
 
    operator fun equals(other: Foo)
}

can't be an override (and also, interfaces can't override methods from Any).

In classes, I don't mind if override is always necessary, because it always is necessary currently anyway. From what is mentioned in the code generation, overriding both equals(Any?) and equals(Foo) in the same class won't be supported, so there's no confusion risk?

[CLOVIS-AI]

The idea of "it's an override but it can restrict the parameter it wants to accept" make me think of https://youtrack.jetbrains.com/issue/KT-79654/Receiver-bound-type-parameters.

They are different features with different use-cases, but they still feel similar somehow: in both cases, the more generic call is mathematically legal, but the compiler should be able to know it's pointless because it operates on vacuous truth.

[serras]

It is somehow related, but one important difference is that for this operator equals we always want to override the equals(other: Any?). This makes it much easier, because we don't need to generate bridges, and we always know what a more specific type means (namely, that comparison outside of it always yields false).

[serras]

Quick update: implementation is in progress.

[CLOVIS-AI]

Would it be possible if the overload syntax was compiled to the annotation?

To me, since it's an annotation that's not particularly pretty (it's not a first-class language concept), this change signifies a change in audience: previously this was a feature for the everyday developer, now it's a feature for 'experts'/library authors/etc: people who are more open to experimenting.

[serras]

Not really, because the whole point of the annotation is to stop having too many special rules for the operator.

In any case, this was always something intended for a small audience. Data, value, and enum classes will get this by default, which means that you mostly want to use this whenever you're defining some sort of hierarchy -- a much less common scenario. But personally, I don't think turning it into an annotation necessarily means it's only for experts: we still intend for the IDE to help you write these bounds if it sees you may benefit from them.

[CLOVIS-AI]

Data, value, and enum classes will get this by default,

Ah, I forgot about that. Then, sure, the most common case will be implementing List/Set and fairly rarely otherwise.

I don't think turning it into an annotation necessarily means it's only for experts: we still intend for the IDE to help you write these bounds if it sees you may benefit from them.

Maybe it would be nice having a nicer syntax for it then?

[serras]

Maybe it would be nice having a nicer syntax for it then?

To be clear: we're actively looking for such a syntax! We've just decided that this feature is useful enough on this form to publicize and begin its experimental implementation. For example:

class List<out A> {
  override fun equals(other: Any? as List<*>) { ... }
}

[CLOVIS-AI]

Ok, the annotation is a good syntax for experimentation.

[whyoleg]

After the latest update of the proposal (c30de3d), it looks like the feature on the declaration site really boils down to adding @Bound(X::class) to the argument of equals member - so my question is: why is it still an operator and not just an override?

If we take the existing code:

class A {
  override fun equals(other: Any?): Boolean {...}
}

To support more specific equals, we will need to do the following (change override to operator and add @Bound):

class A {
-  override fun equals(other: Any?): Boolean {...}
+  operator fun equals(other: @Bound(A::class) Any?): Boolean {...}
}

Why not just add @Bound to the existing override declaration, like this:

class A {
-  override fun equals(other: Any?): Boolean {...}
+  override fun equals(other: @Bound(A::class) Any?): Boolean {...}
}

Sorry if I missed something in the document, but it looks like this "more specific equals" is now just an additional contract for the override. And so it feels that operator here is redundant, as what we do is "override equals behavior to be more strict".

If there is some reason for this to be an operator, it would be nice to mention it somewhere in the document, or point me to the section if I missed it. Thanks!

[whyoleg]

BTW, now that we have @Bound annotation, we can mark it as @MustBeDocumented, and it will be handled and rendered by Dokka automatically.

[serras]

We have decided to split this feature in two phases. There are two reasons: first, it helps us deliver and test the feature step by step; second, there are some small design problems in the custom equality bound front we want to iron out.

In 2.5.0 we'll ship "strict equality for structural classes", which roughly means that you'll get warnings for "wrong" comparisons when using data classes, data objects, final value classes, and enumeration classes. For those cases we know that the compiler-generated equals is correct, so we can take it as the equality bound.

[serras]

Additional update: we've greatly simplified the feature by dropping the code generation part. In more detail:

• @EqualityBound is now an annotation at the class level, not in the equals function
• Since we no longer generate a prologue to equals, we can no longer guarantee that strict equality is satisified, making the smart casting unsafe. So the smart casting was dropped, although it was clear at this point it was not useful anyway.
• We assume that every structural class has an equality bound, even if equals is overridden.