> On May 14, 2018, at 5:02 PM, John Rose <[email protected]> wrote:
>
> Think of V[] as a global type,
> and you'll see that it needs a global definition of what is flattened and
> what is nullable. I think we will get away with migrating types and
> declaring that legacy classes that use their arrays will fail. The mode
> of failure needs engineering via experiment. We could go so far as
> to reject legacy classes that use anewarray to build arrays of value
> type, without putting those types on the ValueTypes list.
>
> This means that if there is a current class C out there that is creating
> arrays of type Optional[] or type LocalDate[], then if one of those types
> is migrated to a value type, then C becomes a legacy class, and it will
> probably fail to operate correctly.
!
I don't think it would be acceptable to change the meaning of code like this:
LocalDate[] dates = new LocalDate[10];
void set(int i, LocalDate d) { dates[i] = d; }
boolean check(int i) { return dates[i] != null; }
*Maybe* when it gets recompiled we force flattening and report an error on the
comparison to null (there are other possibilities, but this is the strawman
language design of record). But if migrating a class to a value class risks
breakage like this everywhere in existing binaries, it's simply not a
compatible change, and I would discourage anyone (including Java SE) from doing
it.
My vision of migration is a lot more inclusive: there are classes everywhere
that meet the requirements for value classes. We want to give those classes a
performance boost, for the benefit of the subset of clients who care, *without*
disrupting the clients who just want a nice abstraction and don't have a
performance bottleneck. We achieve this by encouraging widespread migration to
value classes, and then managing semantics through some form of opt in: opt in,
and you get the full performance benefit, but need to adjust for different
semantics; remain opted out, and your semantics are stable (with perhaps some
marginal performance gains).
