4 ms·

Compared to Java, Kotlin also adds nullable types and sealed classes. The built-in syntax for lambda types could also be considered a part of the type system. O

Compared to Java, Kotlin also adds nullable types and sealed classes. The built-in syntax for lambda types could also be considered a part of the type system. Or the fact that inline lambdas let you use non-local returns (https://kotlinlang.org/docs/reference/inline-functions.html#non-local-returns https://kotlinlang.org/docs/reference/inline-functions.html#...) where the explicit `inline` can be considered a part of the type. As for the others, check out for example TypeScript's mapped types (https://www.typescriptlang.org/docs/handbook/advanced-types.html#mapped-types https://www.typescriptlang.org/docs/handbook/advanced-types....), or Swift's extensions (https://docs.swift.org/swift-book/LanguageGuide/Extensions.html https://docs.swift.org/swift-book/LanguageGuide/Extensions.h...). Considering that Java or C++ don't even have sum types, it's not exactly a high bar to cross.

norswap 8y ago
Fair point for nullables, although that is already possible through annotation processing (see the checkers framework) - but there is a good faith argument that this isn't "core" enough. The syntax for functions and inlining are not part of the type system. Inlining especially, is a useful language feature, and has to be checked at compile-type, but is unrelated with types. Sum types, really you can have that with just inheritance (base class with package private constructor + final sub-classes). What Java lacks is a nice way to pattern-match/switch over types (which Kotlin does nicely with flow typing), but again that isn't really the type system (although it does make the type system nicer to use, certainly).
- realharo 8y ago
  >Fair point for nullables, although that is already possible through annotation processing (see the checkers framework) - but there is a good faith argument that this isn't "core" enough. It also wasn't available in a practically usable form until relatively recently (when talking about history), so my very first point about the timeline of languages still stands. Plus it adds even more verbosity to an already very verbose language. >The syntax for functions I meant function types, e.g. the variable `val a = {}` has a type `() -> Unit`, which is a real type in Kotlin. Of course you can achieve a similar thing in Java with SAM interfaces (including all the weirdly named ones in `java.util.function`), so I'd call that the same level of expressiveness. I don't see why `inline` wouldn't be a part of the type system, when you can have a function argument (that is itself a function) that either - can be passed into anything that expects a function as an argument - as long as the rest of the type matches of course (a non-inline argument) - can only be invoked or passed into another inline function (an inline argument) Conceptually, this has some parallels to C++'s const-correctness ("any matching pointer can go here" vs. "only a non-const pointer can go here", "this function cannot be called via this pointer" etc.), which is generally considered a part of its type system. It's just a matter of definition really. >Sum types, really you can have that with just inheritance (base class with package private constructor + final sub-classes). The person that uses those classes (I'll call them consumer), e.g. writes a function that takes the base class as an argument, then has to be aware of the internal implementation - the compiler won't help you there. If someone else who maintains that part of code adds a new subclass, you'll have an unaccounted for possibility and there is no way to safeguard against that (unless you redesign the whole part of the codebase using crutches like the visitor pattern). There is no good way to express "this value can be one of these types, but no other" in Java's type system from the consumer's point of view (only from the producer's). I may not be using the correct terms here but hopefully you get what I mean. As far as the Java compiler knows, you are not really expressing a sum type, and that comes with the mentioned negative consequences.

norswap 8y ago

Fair point for nullables, although that is already possible through annotation processing (see the checkers framework) - but there is a good faith argument that this isn't "core" enough. The syntax for functions and inlining are not part of the type system. Inlining especially, is a useful language feature, and has to be checked at compile-type, but is unrelated with types. Sum types, really you can have that with just inheritance (base class with package private constructor + final sub-classes). What Java lacks is a nice way to pattern-match/switch over types (which Kotlin does nicely with flow typing), but again that isn't really the type system (although it does make the type system nicer to use, certainly).

realharo 8y ago
>Fair point for nullables, although that is already possible through annotation processing (see the checkers framework) - but there is a good faith argument that this isn't "core" enough. It also wasn't available in a practically usable form until relatively recently (when talking about history), so my very first point about the timeline of languages still stands. Plus it adds even more verbosity to an already very verbose language. >The syntax for functions I meant function types, e.g. the variable `val a = {}` has a type `() -> Unit`, which is a real type in Kotlin. Of course you can achieve a similar thing in Java with SAM interfaces (including all the weirdly named ones in `java.util.function`), so I'd call that the same level of expressiveness. I don't see why `inline` wouldn't be a part of the type system, when you can have a function argument (that is itself a function) that either - can be passed into anything that expects a function as an argument - as long as the rest of the type matches of course (a non-inline argument) - can only be invoked or passed into another inline function (an inline argument) Conceptually, this has some parallels to C++'s const-correctness ("any matching pointer can go here" vs. "only a non-const pointer can go here", "this function cannot be called via this pointer" etc.), which is generally considered a part of its type system. It's just a matter of definition really. >Sum types, really you can have that with just inheritance (base class with package private constructor + final sub-classes). The person that uses those classes (I'll call them consumer), e.g. writes a function that takes the base class as an argument, then has to be aware of the internal implementation - the compiler won't help you there. If someone else who maintains that part of code adds a new subclass, you'll have an unaccounted for possibility and there is no way to safeguard against that (unless you redesign the whole part of the codebase using crutches like the visitor pattern). There is no good way to express "this value can be one of these types, but no other" in Java's type system from the consumer's point of view (only from the producer's). I may not be using the correct terms here but hopefully you get what I mean. As far as the Java compiler knows, you are not really expressing a sum type, and that comes with the mentioned negative consequences.