State of javac support for lworld-values.

[John Rose]

On Mar 26, 2018, at 12:48 AM, Srikanth <srikanth.adayapalam at oracle.com> wrote:
> I think John's "We could assign x.equals(y) as the meaning of x==y for x, y values.  That's a language team choice" allusion is to "logical candidates" in the original document: http://cr.openjdk.java.net/~jrose/values/values-0.html <http://cr.openjdk.java.net/~jrose/values/values-0.html>
> (I realize that these guidelines are just that - they are not enforced and we are likely to encounter code that violates them. So the proposal to have a lint mode in jdk11 has merits)
> 

Sometimes it seems as if we could just DTRT and have op== on a value type VT
invoke VT::equals(VT).  I say that would "DTRT" because after all the VT must
"work like an int" even though it is "coded like a class".  And part of working like
an int is that any equality predicate is (for ints and VTs) properly a by-value
comparison, not the by-reference one that refs support.

Sometimes someone comes up with a reason why fixing op== for VTs is risky.
(Interaction with generics causes potential problems, for example.  So does
migration from VBC's.)  I think it's safest to avoid op== completely for VT's,
for now, while trying to steer for a place where we can unify op== on non-ref
types to mean some kind-of type-specific equals.

For a lint-mode this means reporting (truthfully) that op== is probably the
wrong thing for a value-based class.  For new value types, we can disallow
op== (temporarily) until things clear up.

For now, that's about as clear as mud, I know.

I like the idea of linting VBC's on their way to becoming proper VTs.

— John