[External] : Re: Revisiting default values
brian.goetz at oracle.com
Mon Mar 22 17:08:39 UTC 2021
> Two things: firstly, the function wouldn't need reified generics to
> work. If you rename it to "newInitializedArray" (which makes more
> sense in the first place) and document that "initializer" must not be
> then you're done: the array's component-type would be the
> initializer.getClass() or initializer.getDeclaringClass() for enums.
> secondly, the term "valid default" is misleading here. You wouldn't
> need such a universal value for every type. You'd just need a
> reasonable value to pass every time you call this function.
> This value could well be different on every invocation to suit your
Good news: now I understand what you're suggesting.
Bad news: it's not a very good idea, for many reasons.
First, it conflates language and library design; newArray() becomes a
special magic method that users can't write, only the JDK can have it,
and the language has to bless it. This is a tangling of concerns that
should be a hint.
Second, it still doesn't solve the underlying problem of Bucket 3, which
is making it safe to use uninitialized fields or array elements. You're
positing a T value that is a valid initialization value, maybe not for
all cases, but still for any code path that might be exposed to this
array element. But you've only made the problem slightly simpler, and
there still may well not be any such value. Worse, because the
"uninitialized" value is instantiation-site-specific default, no one
will be able to even ask "is this the default value."
Better to just tell people "don't expose fields, and check for default
explicitly on entry to every method." (Which still isn't a very good
This game is hard...
>> On 3/20/2021 8:50 AM, Brian Goetz wrote:
>>> I get where this is coming from, but I think it's misguided.
>>> First, zero-hostile is a bad default. The #1 use case for primitive
>>> classes is numerics, so the defaults should be tailored to their needs.
> Hmm, not really. The usecase that I was presenting with the
> "Collection#toArray" example was explicitly about restricting the
> applicable types to the _sub-set_ of the "zero-defaultable" ones.
I get that you want to be able to do this, and I agree it would be nice
to do so. What I'm saying is that your proposal distorts a big feature
for the sake of a little one; that's another of those hints we shouldn't
ignore. Zero-hostile is not the right default for primitives; flipping
it for the sake of "I want to express a bound here" is the tail wagging
the dog. I'm not saying the bound isn't useful; I'm saying you're
getting caught up on a specific solution rather than bringing clarity to
the problem. If you bring clarity to the problem, the solution is often
This game is hard.
More information about the valhalla-spec-observers