![]() Kotlin calling Java: you have to manually check return values for older libraries and won't notice where you're passing in null because that's a normal, safe thing to do when calling Kotlin. Kotlin calling Kotlin: you use null a lot, you never hit a problem with null. Scala calling Java: you have to manually check return values for older libraries but at least passing in null can't happen. Scala calling Scala: you never use null, you never hit a problem with null. > Kotlin's approach is superior in that it requires developers to deal with nullabilityīut it doesn't force them to deal with nullability when interacting with Java which is the only case where it matters. Why do you want an extra way of representing the same thing with more special cases? ![]() It's certainly not worth the cost of working with a weird, second-class type that you can't abstract over like other types). I don't know how to constrain the contract properly.Nullable types are worse than Option in every way that matters (yes they save a few bytes of memory occasionally, but who the hell cares, if you care about shaving 8 bytes off an object you won't be using the JVM in the first place. The problem is that it seems pretty dangerous if you don't actually return in the passed lambda then it still smart casts. IMHO, the best approach (though I don't know what to name the function) is: fun anyNull(t: T?, u: U?): Pair?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |