Probably Java 10 will get value types. Are there already plans to support such a construct?
I wonder how value types would affect Kotlins approach to null handling, since Java’s Optional could become a value class, so that there wouldn’t be any memory overhead. Since Kotlin developers are using mostly Java libs the concept of Optional could become dominant even in Kotlin code. In any case there are two approaches to null handling. Although I like Kotlins approach, I’m not sure how future proof it will be considering particularly value types. What do think?
Kotlin is definitely going to support Java 10 value types. I’m not sure how this idea leads to the idea of “Optional could become dominant in Kollin code”.
Java 10 is going to be released, give or take, five years from now. During these 5 years, using Optional will be causing memory overhead, so there will be 5 years worth of Kotlin code written without using Optional. Also, all the syntax sugar support that Kotlin has for dealing with nullable types will not apply to Optional (neither now nor when Java 10 is released).
Therefore, I don’t see any reason to expect that many people will start using Optional in pure Kotlin code even after Kotlin gains support for value types.
I might be wrong, but for all intents and purposes isn’t T? already isomorphic to Option<T>?
i.e., if you’re not using null values, using T? gives you the same capabilities as Option<T> but with a nicer syntax for the type, and .? is really just map while ?: is getOr.
That being said, I support value type, but they’re tricky to implement on the current JVM. Not having them is a huge pain in the butt if you care about performance.
And actually Scala value classes are not like the Java proposal. Scala value classes are a way to alias primitive type (a single int/double/whatever), while Java value classes are more akin C’s structs.
I’m happy to hear, that value types will be supported. My point was, that Java’s Optional could become the default in Kotlin, because there are (or will be) so much Java libs that make use of Optional. However, you’re right that there is some time until Java 10, much time for Kotlin to get traction …
@norswap: I see some more differences between T? and Optional<T> or at least between T? and Scala’s Option[T]. I’m not aware of something similar in Kotlin:
scala> List(None, Some(2), Some(3), None, Some(5)).flatten.sum
res0: Int = 10
And, yes, Scala’s value types are somewhat limited at the moment, due to limitations of the JVM. But they are nice anyway, for example to distinguish measurement units by types.
That’s right and perfectly reasonable. What I meant is that flatten is no special method for null or None. Scala’s Options has the same general abstraction as a collection, while T? is a special case, which needs special methods. This example shows what I mean:
scala> List(List(None, Some(1)), List(Some(2), Some(3)), List()).flatten.flatten.sum
res13: Int = 6
The first flatten flats the lists, the second the Options.
However, Kotlin is not Scala and shouldn’t be. I just wanted to show the consequences of different styles of null handling.
In fact, you can add corresponding extension functions to Optional / Iterable<Optional<T>> (Array<Optional<T>>, Sequence<Optional<T>>).
Lack of overloadable ?. / ?: / !! bothers me, too, but just a little bit. Note that ?. / ?: / !! affect control flow analysis (just like || and &&), and, thus, flow typing. It would be rather hard to ensure that the same properties hold true for user-defined “optionality” operators.
No value types though 