Here are two examples of where a B2 class could safely and
beneficially use B2.val:
value class Rational {
Rational[] harmonicSeq(int n) {
Rational.val[] rs = new Rational.val[n];
for (int i=0; i<n; i++)
rs[i] = new Rational(1, n);
return rs;
}
}
Here, we've made a _flat_ array of Rational.val, properly
initialized it, and returned it to the user. THe user gets the
benefit of flatness, but can't screw it up, because of the array
store check. If Rational.val were illegal, then no array of
rationals could be flat.
but you are leaking Rational.val as the class of the array, so one can
write
var array = Rational.harmonicSeq(3);
var array2 = Arrays.copyOf(array, array.length + 1);
var defaultValue = array2[array2.length - 1];
I'm going to ask you, again, to choose your words more carefully.
It seems you are suggesting "this model is bad because look, here's a
hole." If that's what you mean, this is a very inappropriate way to
engage. This is a high-level discussion of user model; to pick nits
over bad assumptions about low-level details that haven't even been
discussed yet, and then use to cast doubt over the design, is the height
of unconstructive interaction.
If what you mean is "This is great, but don't forget we'll have to
address the accessibility model", then you should say that. But OF
COURSE we have to defend the accessibility model. This is an obvious
and normal part of the design process (in fact, John and I were talking
about this not one hour ago.) Don't forget that Object::getClass leaks
class mirrors too! But there are other checks to prevent bad things
from happening.
Currently we live in a world where apart of using jdk.unsupported,
there is no way to get an uninitialized object even by reflection,
you propose to shatter that idea and to allow to bypass the
constructor and have access to the default value directly in the language.
Words like "shatter" are unnecessarily inflammatory. Worse, leveling
inflammatory accusations before you've even understood what is being
proposed, is completely unconstructive.
Further, you have been working with us for long enough that you know
that we don't casually undermine the safety of the programming model.
So if what we're proposing sounds dangerous, you should think first that
maybe you don't fully understand it, before making accusations?
Please -- do better.
