Re:Project Valhalla, Explained: How a Decade of Work Arrives...
by wiseowise on Friday June 19, 2026 @11:35AM
(#48599795)
Nothing stops me from sticking my dick into a blender either, yet it works fine for most of the things (the blender). Both Java’s notion of final and Kotlin’s nullability work great for 99.999 use cases and you really need to go out of your way to break them.
Re:Project Valhalla, Explained: How a Decade of Work Arrives...
by inigyou on Saturday June 20, 2026 @09:35PM
(#48614843)
If you can get a null into a nonnull variable, it can propagate all over the program and people will be defensively checking for it everywhere - final is not like this.
Re:Project Valhalla, Explained: How a Decade of Work Arrives...
by tadfisher on Friday June 19, 2026 @05:51PM
(#48603676)
Kotlin works around this by not exposing the backing field directly; a "field" becomes a "property" which has a getter and setter under the hood. Attempts to read uninitialized properties are compile-time errors. You can turn these into runtime errors using the "lateinit" keyword.
Kotlin still has a hole where you can run code in "init" blocks which are executed sequentially on object construction; in one, you can call a function that is defined after an unmodifiable property, and it will see the uninitiailized value.
There's a whole bunch of specification language describing how constants aren't actually constant in specific situations.
I don't know Kotlin but I assume it does the same thing: until the non-nullable field gets initialized, it holds null and violates the type system.