Questions on default values

[Stephen Colebourne]

On Fri, 19 Mar 2021 at 18:57, John Rose <john.r.rose at oracle.com> wrote:
> On Mar 19, 2021, at 7:43 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> Is this analysis correct?
> (If so, then I'm pleased. I wrote some "requirements" in July 2020
> exactly along these lines but never sent them to the list)
>
> The fact that you're pleased is not necessarily encouraging, sad to say; it's evidence for our biggest concern about this approach, which is that it will be an attractive nuisance ("Finally, my nullable value types"), developers will be unaware of the performance tradeoffs they are making, and then conclude "value types suck."
>
> The feature here is *not* "nullable value types", as much as some would like that to be the feature!  The feature here is "detection of uninitialized primitives."  It is convenient that the latter travels through null, but null is a means to the end, not the end.
>
> Piling on:  The idea of vull/null transcoding is about two years old,
> and has been discussed at length in Valhalla design meetings,
> with non-Oracle people present, though (sadly) not minuted
> externally.  I find it a most charming idea.
>
> The reason it has not seen more wide distribution is that it has
> hard-to-control performance implications, as Brian points out.

I find the performance issue odd. The comparison I see is a flattened
YearWeek with a check on method access vs a cache miss memory hop. My
understanding was that the cost of the memory-hop dwarfs the branch.

Numeric classes are the ones where absolute performance matters most,
and those will usually have a zero default, so again the fear seems
over-done.

> That is true even if you allow a “pivot field” to improve vull
> detection.

I'm no expert, but it would seem even if you chose a simple
memory-inefficient approach such as an extra up-front byte to
determine nullness it still wouldn't be as wasteful as a reference
which wastes 4 or 8 bytes and a memory hop.

> It is *not* a requirement

I definitely differ here. For me, it is a requirement that classes
like YearWeek with no good default are flattened. Otherwise, what is
the point of valhalla? And the only good representation of the
uninitialized value is null/vull. Not doing something like this will
result in libraries chock full of atrocious defaults, which would be
an absolutely dreadful outcome. We don't want some poor soul to have
to write yet another date and time library, with awful defaults, just
to get the benefits of flattening.

So, no I don't think that valhalla generics are more important than
getting the basic model for NoGoodDefault values right - we can wait
for the generics, but we can never fix a broken fundamental core
design.

> The ref-favoring model exists to support _compatible migration_ for classes like Optional

I think you already know that I think LocalDate should simply become
flattened when valhalla arrives. I don't think asking developers to
write LocalDate.val to get flattening is acceptable.

Stephen