4 ms·
What I want: No object/primitive distinction, but you have to explicitly make objects and methods nullable, and the dereference operator is null-safe. (You use
by TheLoneWolfling 13y ago
What I want:
No object/primitive distinction, but you have to explicitly make objects and methods nullable, and the dereference operator is null-safe. (You use the dereference operator on a null object, you get null. You use the dereference operator to call a nullable method on a null object, you get null. It is a compile-time error to call a non-nullable method on a nullable reference where the compiler cannot prove that it won't be null. Pure functions are implicitly nullable.)
It is a compile-time error if you assign a nullable reference to a non-nullable reference and the compiler cannot prove that it won't be null.
I've also had an idea for what I call a "pseudo-statically typed" language: instead of checking types at compile time, it checks that you implement all functions called on the parameter at compile time. Public variables are just syntactic sugar for getX/setX, operations are just syntactic sugar for addX/subX/etc. If you define a method with an input type of X, the compiler checks that you only call methods that are defined in X, and then replaces the type with the methods actually called.
But nullable "primitives" can actually be useful occasionally, for caching, for example. Having a separate boolean flag works, but can be inefficient (you can store null internally as NaN with a specific payload, for example, whereas a boolean flag generally requires at least a byte, more with alignment. This also allows easier atomic updates.)
- laureny 13y agoKotlin seems to do exactly what you want.
- TheLoneWolfling 13y agoNo checked exceptions, which for me is a dealbreaker.
- laureny 13y agoI sympathize, I think checked exceptions are a good idea overall, just poorly used in Java, but the current trend of languages is clearly showing that we're moving away from the idea. None of the languages that came out on the JVM these past ten years (Scala, Groovy, Clojure, Kotlin, Ceylon, etc...) support checked exceptions.
- dinkumthinkum 13y agoNo checked exceptions is a deal breaker for you for a programming language? What kind of deals are you making?
- jaxytee 13y agoOne with the programming underlords.
- anonymoushn 13y agoAs someone who writes Scala most days, this feature of Kotlin looks pretty great.
- esrauch 13y agoGoogle's Closure JS Compiler has exactly what you are describing as an optional layer on top of Javascript inside jsdoc comments. In that, primitives are default non-nullable unless you include ? in the type (eg @type {number} is non-nullable, {?number} is nullable), whereas Objects are nullable by default unless you specify otherwise (eg @type {Object} is nullable, {!Object} is non-nullable). It's a pretty good system that does what it can, but you can still pretty easily get code that violates your specified types at runtime if you go out of your way.
- NickNameNick 13y agoMaybe http://whiley.org/ http://whiley.org/