Value types, encapsulation, and uninitialized values

[Kevin Bourrillion]

Sorry for slow response.

It is true that there exist value types which have a "zero", which I would
define as some *natural* choice of default value that will be *blindingly
obvious* to any consumer. Of course, Point/Complex are the same two
examples that had leapt to my mind. These are the best case, the only value
types that will *really* (almost) join the same category as `int` and
`double`.*

Unfortunately I suspect these are very rare in practice. Most code is
business logic, and most business aggregate "values" probably don't have
safe defaults. Worse, I suspect that what few there are are probably
outnumbered by types like Instant that have a *false* zero. If users
implement these as value types in a way that elevates treats their false
zero like a real zero, I think that would be sad. These are only
suspicions, which I could do more work to substantiate based on our
codebase. (That work just has to go onto the old to-do list.)

Most value types, I think, don't have a zero, and I believe it will be
quite damaging to treat them as if they do. If Java doesn't either provide
or simulate nullability, then users will be left jumping through a lot of
hoops to simulate nullability themselves (`implements IsValid`??). This
looks like a very bad outcome to me, and this has been one of my major
concerns about the whole feature for the last couple years. (It's a relief
for me to see you sharing the same concerns to some degree.)

These zero-less types we could divide into two groups: those that at least
have some combination of field values that is *invalid*, and those that
don't, and are unwilling to add a field now in order to achieve that. The
latter have no possible way to be nullable, and the former have a possible
way to be nullable that is just plain *weird* (user provides a sample value
that is not allowed to actually exist, so that that can be used as the
internal representation of what is surfaced in the language as null.). As
weird as that is, at least it would provide actual nullability instead of
awkward attempts to simulate what nullability already is, so I think it
actually does a better job of confining the weirdness?

(*I'm glossing over the fact that the existence of these zeroes still isn't
always a great thing; the inability to distinguish between intentional and
accidental zeroes is already a (very minor) source of bugs today. It's
unclear what purpose is really served by an array of Durations being
initialized to all zero-length durations.)

On Thu, Oct 11, 2018 at 7:14 AM Brian Goetz <brian.goetz at oracle.com> wrote:

So, some values (but not all) will want some sort of protection against
> uninitialized values.  One approach here would be to try to emulate
> null, by, say, injecting checks for the default value prior to
> dereferences.


In this case, it's more than just a default value, it's that the user
provides any example of a *bogus* value, and the best way I can think of
for Java to handle this would be to surface it as *null* itself. Otherwise
you're inventing a second kind of nullability. Granted though, this is
weird. But it has a lot of good properties.

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com