If I have the following code

class Something
{
  Button button 
  new make()
  {
    doSomeInit()
  }
  Void doSomeInit()
  {
    button = Button()
  }
} 

It does not detect that button is inited and so I have to make it nullable

What also can be done is that non nullabe class fields can inited as null when to object is created, but they can not be == or = to null. This will keep the nullable system working fine as the system can just expect that the fields will be inited somewhere. At least in the current design I have to make many field nullable while they are in fact not, which make the code look more ugly.

That is sort of the same problem with Java's final fields - you have to set them in the constructor, otherwise the compiler doesn't know that they have been set.

I'm not sure what else we can do there though. I suppose we could use some facet, but that seems worse than having a nullable type?

When I make a type non nullable, it tells me, someone else who read my code and the compiler the field should can not be zero.

This means that in any operation that I do which this field it can not be null, so this means that the first operation all types of operation are invalid expect the

this.somefield = someval //init the field

operation.

So my suggestion is to set the field to undefined(Obj.undefined) when it gets inited in a object where no default value is given.

In this way there is no need to detect whether the field is inited in the make function.

There is no concept of undefined in the JVM, so we pretty much have to make it work with null. Really in this specific case we have all the same issues Java has with forcing an instance field to be final, and they have pretty much taken same trade-offs us. In practice (although annoying somethings) I've find both Java final or Fantom non-nullable checks to be fairly easy to work - just have to do sets in your constructor. In your example:

new make()
{
  button = initButton()
}

Button initButton()
{
  Button()
}