Would it make sense to have equals rely on type ch...

# compiler

[pablisco]

Would it make sense to have equals rely on type checks instead of using the default JVM implementation that uses the instance id? Maybe the compiler could add these default implementations:

sealed class Location: Serializable {
    object Unknown : Location() {
        override fun equals(other: Any?) = other is Unknown
        override fun hashCode() = toString().hashCode()
        override fun toString(): String = "Location.Unknown"
    }
    data class Known(val lat: Float, val lon: Float) : Location()
}

https://stackoverflow.com/a/56485743/458365

[karelpeeters]

Isn't that a bug in the deserialiser? It should just return the real object instance instead of creating a new one. You don't want to have multiple instances of the same singleton hanging around anyway.

[karelpeeters]

This feels like a band-aid solution to a very superficial problem caused by breaking the fundamental singleton guaratee.

[pablisco]

Well yeah, it's a hack, but so is most of the bytecode generated by Kotlin to be able to do what it does on the JVM. Not really a bug in the deserialiser since the JVM doesn't support singletons natively...

[aballano]

related ticket: https://youtrack.jetbrains.com/issue/KT-9499