Substitutability, was Re: Finding the spirit of L-World

[Brian Goetz]

> PS. How bad would it really be to change NaN == NaN to be true?
> Wouldn't any breakages be pretty minor?

It would be minor in the sense that floating point is a small minority of use cases, but for those who do a lot of floating point, it might well be significant.  (There’s also the anomaly of neg vs positive zero, which == treated as different but Float.equals() treat as the same.)  

Where this bites us, in a small way, is: we’re going to have some sort of value wrappers for primitives (either the existing wrappers, migrated to values, or some new ones), and the way we’ll put doubles in a HashMap is by wrapping them with a value.  (This is what lets us sidestep specialization issues like the irregularity of the bytecode set across types, or the fact that longs and doubles take two stack slots.)  And the semantics of `==` on the double wrapper will diverge slightly from the semantics of `==` on double (as it does now between double and Double.)  But, if we’ve been being bitten by this for 25 years, and it hasn’t bothered us too much yet, we’re probably OK.

> To be honest, .equals() is one of the verbosity reasons I see pushing
> people to alternate JVM languages. And this is going to come up again
> with any future operator overloading discussion. I'm pretty sure an
> operator would be widely welcomed.

That’s a fair concern, but a separable one.  I don’t think it either helps or hinders the current discussion (though it may obfuscate it a bit); that’s more of an Amber-like “ceremony reduction” thing, that we could just as easily tackle before or after.  Given the already-huge scope of Valhalla, I’d rather focus on the fundamentals right now, and not add in too much additional opportunistic tinkering.

The mistake I’m trying to avoid right now — which would be a serious and fundamental one — is to get the definition of `==` wrong.  That’s the important thing to focus on right now.