Value types design decisions

[Brian Goetz]

Forgot to address this part.

On 1/20/2024 2:00 AM, Smith Wilson wrote:
> It could solve problems with such classes like LocalDate which require 
> more special zeroInstance (1970-1-1) than value with pure defaults.

The key thing to realize about LocalDate is that while it is a good 
candidate for being a value type, there is *literally no* good default 
value.  Jan 1 1970 is not a good default value, as we've all seen by 
getting emails that tell us our subscriptions are going to expire 54 
years ago.  No other specific date is a good default either.  This is a 
statement about the _domain_; there is no good default.  (And when an 
abstraction does not have a good default, null is your friend.)

Other classes have good defaults; Duration is such an example.

These two examples (conveniently, from the same package) tell us a truth 
about modeling data with value objects: some classes have reasonable 
defaults (and we can exploit this to optimize their treatment, and can 
freely let people use uninitialized variables, as we do for primitives 
today), and some do not (and hence we need either to engage nullability, 
or work very hard to ensure that an object cannot possibly be used 
uninitialized.

The reason that "implicit constructor" is a thing is that, even after 
we've identified that a class is a value class, we still have to 
identify something else: whether it is implicitly constructible or 
requires explicit construction.  (There's other ways to frame it, of 
course, but the key is that this has to be in the programming model.)