Spiega il funzionamento degli operatori '==' e '===' in Kotlin. Qual è la specificità del confronto tra oggetti e tipi di valore, cosa succede sotto il cofano durante il confronto e come evitare l'errore comune di equivalenza?

Risposta.

In Kotlin ci sono due operatori per il confronto:

• == — confronto strutturale (equivalente a .equals()). Controlla il contenuto: a == b chiama a?.equals(b) ?: (b == null).
• === — confronto per riferimento. Controlla se entrambe le variabili puntano allo stesso oggetto: a === b è equivalente a Java a == b per gli oggetti.

Per i tipi primitivi (ad esempio, Int): == e === possono comportarsi allo stesso modo a causa del boxing automatico, ma in generale si consiglia di usare ==.

Esempio di codice

val a = "Kotlin"
val b = "Kotlin"
val c = a

println(a == b)    // true (confronto del contenuto)
println(a === b)   // false (riferimenti diversi — le stringhe sono internate a seconda del compilatore)
println(a === c)   // true (stesso oggetto)

---

Domanda trabocchetto.

Qual è la differenza tra a.equals(b) e a == b in Kotlin?

Alcuni sostengono che non ci sia differenza, tuttavia se a è nullable, la chiamata a.equals(b) genererà un NullPointerException, mentre a == b è sicuro e restituirà true se entrambi sono null, o false se solo uno di essi è null.

Esempio:

val a: String? = null
val b: String? = null
println(a == b)       // true
println(a?.equals(b)) // null (e non true, ma non è un crash)
println(a.equals(b))  // NullPointerException

---

Esempi di errori reali a causa della mancanza di conoscenza delle sottigliezze del tema.

---

Storia

In un grande progetto si confrontavano attivamente stringhe nullable tramite a.equals(b), senza sospettare che con a == null l'applicazione crashava. Il bug si ripeteva piuttosto raramente, ma portava a crash fatali in produzione — è stato corretto sostituendo con a == b.

---

Storia

Confrontando oggetti tramite ===, ci si aspettava un confronto del contenuto, ma === controlla l'identità degli oggetti - si è scoperto che due diverse stringhe con lo stesso contenuto non erano uguali tramite ===, il che ha danneggiato la logica di caching dei dati.

---

Storia

Lavorando con valori boxed Int (ad esempio, da collezioni), gli sviluppatori li confrontavano tramite === e ottenevano risultati inaspettati a causa del fatto che le istanze oggetto di numeri diversi non sono necessariamente internate come i primitivi. Ciò portava a comportamenti errati durante l'utilizzo di collezioni di oggetti.