questions on nullability

[Lars T Hansen]

(redacted) writes:
 > lth at opera.com writes:
 > > The entire reason that the class definition can be annotated is to
 > > make it easier for the programmer not to have to worry about null when
 > > using classes for which a null value does not make sense.  The
 > > canonical example is "Complex": this is usually viewed as a "value
 > > type", ie, it does not normally make sense to have Complex values that
 > > can be null.
 > 
 > Isn't there then an argument for adding a syntax to provide a default value
 > in place of null, much as int or Number are defaulted to 0? 

That would not prevent you from later assigning null to a variable of
that type, though, or pass null to a function taking that type.

The intent of the non-nullability proposal is to be able to add
annotations to the program that guarantee that that sort of thing will
not happen, and that null-pointer exceptions won't be thrown.  It goes
beyond creating sensible non-null default values.

There has been rather a lot of discussion about whether default values
could be provided for non-nullable variables; the discussion page for
the proposal records some.  In practice default values are fraught
with issues, not the least because you'll want default values to have
"value semantics": to be either read-only or copy-on-write.

--lars

(CC'ing the discussion list even though I received the reply
privately; it's of general interest.  Sender's name redacted.)

 > Just a stab at
 > the syntax here but, to use your Complex example:
 > 
 > public class Complex extends Object = new Complex (0,0) {
 >      //
 > }
 > 
 > 
 > public class Complex
 >     extends Object
 >     default new Complex(0,0)
 > {
 >      //
 > }
 > 
 > This would be far more useful than simply banning null. I would expect the
 > statement defining the default value could be made up from any static
 > methods or compile-time constants.