связана с тем, что JVM реализация listOf не учитывает кривость Java реализации коллекций.
Вот для примера, накидал на коленке реализацию, у которой нет такой проблемы:
private class DelegateList<out E>(private val src: List<E>) : List<E> by src {
override fun equals(other: Any?) =
this === other ||
other is List<*> &&
size == other.size &&
asSequence().zip(other.asSequence()).all { (x, y) -> x == y }
override fun hashCode() = src.hashCode()
override fun toString() = src.toString()
}
fun <T> myListOf(t: T): List<T> = DelegateList(listOf(t))
fun <T> myListOf(vararg ts: T): List<T> = DelegateList(listOf(*ts))
fun main(args: Array<String>) {
val l1 = myListOf(1)
if (l1 is MutableList) {
l1 += 2
}
println(l1)
val l2 = myListOf(1, 2)
if (l2 is MutableList) {
l2 += 2
}
println(l2)
println(l1 == l2)
}
вы мыслите платформой, а я языком котлин. И я повторяю что знаю про эту дичь с колекциями, в сорцы умею заглядывать, не нужно мне пересказывать что я и так знаю. нашел этот костыль давно и предлагал дополнително проверять на джавовские реализации пустого и одиночногго списка.
Обсуждают сегодня