Fwd: Default values vs nulls

[Brian Goetz]

Received in the -comments list.

The synthetic value you are describing is what we have been calling 
(somewhat pejoratively) "vull"; a special sentinel for this value is 
uninitialized.  When you pull on the vull string for a bit, it becomes 
apparent you are creating a poor reinvention of null.


-------- Forwarded Message --------
Subject: 	Default values vs nulls
Date: 	Thu, 6 Aug 2020 11:04:21 +0200
From: 	Hontvári Attila <attila at hontvari.net>
To: 	valhalla-spec-comments at openjdk.java.net



(resending, previous email had a confusing ending, ignore that)

The currently discussed solutions to the problem of uninitialized bucket 
#3 values mostly seems like the following: the value set of the type is 
extended with a special value that throws an exception if somebody 
invokes a method on that, but instead of the name "null" it has a new 
name and syntax: "V.default". But if we take for example a LocalDate, it 
is a bit strange to say the fields with type LocalDate.val are 
initialized to "LocalDate.default", because that type doesn't have an 
acceptable default value: the variable just has no LocalDate value if 
somebody haven't set one, and null means exactly that. This creates a 
split between non-initialized reference types and inline types, which 
might be unneecessary. It might be worth to investigate Option J, that 
solves this by treating uninitialized default values as nulls, but 
hasn't got as much attention as some other options.