4 ms·
Someone in an earlier Kotlin discussion (there has been quite a few just today) was praising how Kotlin solves the "1M$ mistake" having no null. He was also com
by dullgiulio 9y ago
Someone in an earlier Kotlin discussion (there has been quite a few just today) was praising how Kotlin solves the "1M$ mistake" having no null. He was also complaining that sadly is day-to-day job involves Go.
Unline Kotlin, Go does support len() (.length in Kotlin) on nil: https://play.golang.org/p/koqYbIdltw https://play.golang.org/p/koqYbIdltw
In Kotlin, b.length can throw a NPE, only a b?.length won't (it will return zero or null, I have not understood that).
Together with the var/val debacle, it seems like it is designed to be very terse, which can lead to easier errors.
I don't think it solves the 1M$ mistake at all. And how could it, while maintaining full compatiblity with Java?
- barrongineer 9y agob.length on a nullable type wouldnt compile in Kotlin.
- Filligree 9y agoThe only way b.length would compile, if b is a nullable array, is if it's defined in a Java class. In which case Kotlin will assume it's non-nullable in the absence of nullability annotations. That is not perfectly ideal, but it's not Kotlin's fault; they decided (rightly, I think) that the reduced friction is worth the risk. And you can add annotations. If b were defined in kotlin, as nullable, then b.length is a type error. You can use b?.length, or you can add an explicit null check and depend on the smart cast.