Paraméterben Option-t átadni eleve valami nagyon rossz tervezésre utal. Pl. miért nem lehet overloadolni a metódust egyszer nulla, egyszer pedig egy paraméterrel? Vagy esetleg olyan típusú objektumot adsz át, aminek egy metódusa Option-t ad vissza, és a függvényed meghívja az adott metódust az átadott paraméteren? Aztán lehet ennek a típusnak olyan megvalósítása, ami ad vissza valamit, meg olyan, ami nem.
Láttam már a Kotlin megoldását, meg azt is tudom, hogy a nyelvet a Scala inspirálta, meg azt is, hogy pont el akarták kerülni az Option használatát. :) Valóban van hasonlóság a két megoldás között, viszont az Option okosabb, mert egyben használható, mint 0 vagy 1 elemű collection, ami sokszor elég hasznos tud lenni, míg ezzel a megoldással néhány dolgot (szerintem) nem tudsz szépen megoldani, pl.:
val a: Option[Int]
a.contains(42) // a == Some(42)
a.exists(_ == 42) // mint a contains, Scala 2.10-ben még nem volt Option.contains
a.forall(_ == 42) // a == None || a == Some(42)
val b: Int?
a == 42 // mint fent a contains vagy az exists
a == null || a == 42 // mint fent a forall
a ?: 42 == 42 // szintén forall, szerintem ronda hack a nullcheck elkerülésére
// egyéb megoldás?
Igaz, arra tényleg nincs garancia Scalaban, hogy egy referencia ne lehessen null, de a gyakorlati tapasztalatom azt mutatja, hogy lehet olyan kódot írni, amiben egy referencia soha sem lesz null. Mi ezt megtámogatjuk statikus kódellenőrzéssel (a build failel ha null-t talál a kódban), illetve nem használunk olyan libraryket, amik nullt adnának vissza.