A modern programming language that makes developers happier.

kotlinlang

image.png

Okay. I'm encountering, of all things, a *potential critical bug* with `kotlin.collections.ArrayList.indexOf`. I think it's critical, but maybe not.  There are fixes but `indexOf` doesn't properly work for me in certain cases ( version 1.3.61)

Premise: `val questionsAndAnswers = mutableListOf&lt;Any&gt;()` , in practice containing items of types data class Answer and data class Question. Both have `equals(other: Any)`  overriden to return true only when other is of the same type.

equals in Answer
```override fun equals(other: Any?): Boolean {
            return (other as? Answer)?.proof?.sourceNode?.getContentId() == proof?.sourceNode?.getContentId()
}```
equals in Question
```override fun equals(other: Any?): Boolean {
            return (other as? Question)?.item?.getContentId() == item?.getContentId()
}```
I do `questionsAndAnswers.indexOf(answer)`  knowing my answers are only add odd indexes, and I get a 0. I expected either -1 or odd. Check the debugger, i mapped a bunch of data to help troubleshoot

TL:DR
```questionsAndAnswers.indexOf(answer) =&gt; 0
questionsAndAnswers.indexOfFirst { it == answer } =&gt; 1
questionsAndAnswers[0] == answer =&gt; false```


Also
``` questionsAndAnswers.map { it == answer } =&gt;  size = 3, values are false true false```

"false true false" was expected behavior. I instead get false true true as you can see in debugger, even though `questionAndAnswers.map{it.javaClass}`  gives me `[Question,Answer,Question]` making the 1st item true impossible. Something is not working right

I can see it being a problem if when you do indexOf interally you first filter by the type that is passed, so indexOf(something at index 1) returns 0 because it is the first item in a list of &lt;ParentType&gt; of that type after filtering

Any nuclear plants using Kotlin? Maybe it's not too late :cry:

Most likely your `equals` implementation doesn't satisfy one of these contract requirements:
<https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-any/equals.html>

For example, if `this.proof` is null, then the Answer would be equal to _anything_, which is definitely not symmetric.

specifically, if `other` is a Question, and `this.proof` is null, that equals method will return true (as null is equal to null), which appears to match the screenshotted case

You're both right! I'm back a long while later. It was exactly that.

I wouldn't have picked up on it being a problem if different equal functions wouldn't return different equals for the same value. I feel like due to the results, it looks like when doing different list functions which compare values of different types o1: A and o2: B, there isn't consistency between which one's equals function is used.

&gt;  I think it's critical, but maybe not.
My thinking was wrong :laughing:  big of me to put a bug happening in my code on the language :man-facepalming:

&gt;  it looks like when doing different list functions which compare values of different types o1: A and o2: B, there isn’t consistency between which one’s equals function is used.
That is exactly correct, which leads to the importance of symmetric equals() implementations. And hence to the difficulty in having data classes extending each other- two siblings in the inheritance tree are unlikely to be able to have symmetric equals() implementations. This issue crops up more with comparator/comparable though in my experience.