I just noticed that non-nullable fields can be left uninitialized. They seem to follow the underlying Java automatic initialization rules (defaulting Ints to 0, and objects to null, etc).

class Main
{
  Str foo
  Void main()
  {
    echo(foo)
    foo = "a real value"
    echo(foo)
  }
}

Will print

null
a real value

Really, it should be a compiler error.

This is a known problem waiting on resolution of the whole with-block/builder discussion.

I should also add, I noticed this when looking through the serialization docs. In particular, I was curious how to interpret @transient fields that were non-nullable. The doc for serialization was written before the non-nullable change was put in, and the example shows a transient non-nullable Int, which I have a feeling wouldn't fly even if the compiler properly prevented uninitialized non-null slots.

Good point. I think such fields probably need a new annotation, something like:

@transient
@onSerialize=#precomputeHash
Int hash

(Assuming precomputeHash is an Int returning method accepting no parameters.)

good catch on the docs - I will take a look

as John said, the compiler will eventually check that stuff, soon as we figure out ctor/with-block final design

Yeah. I keep seeing quirks in the language which I want to bring up on these forums, but when I do, I see it's closely related to constructors.