[External] : Re: Revisiting default values

[Brian Goetz]

> 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 
> null,
> 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 
> needs.

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 
answer.)

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 
apparent.

This game is hard.

Cheers,
-Brian