State of javac support for lworld-values.
john.r.rose at oracle.com
Mon Mar 26 23:50:25 UTC 2018
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.
More information about the valhalla-dev