acmp again !

[Brian Goetz]

> Again pick your poison. 

The phrase "pick your poison" is misleading because it suggests all 
poisons are equally fatal.  And these two poisons are very, very 
different.  (Alcohol is a poison, and when taken recursively can indeed 
be fatal, but that's not the usual outcome, nor is it usually a deterrent.)

With the "always false" semantics, a fundamental building block of the 
language has perennially astonishing semantics in situations that will 
be routinely encountered by all users.  (We've seen languages where the 
`==` operator has semantics people can't understand; we don't want to be 
them, or have to deprecate `==` in favor of `===` because the language 
failed so hard the first time.)

With the second, the performance will sometimes be mildly surprising 
when some wise guy thinks he's being clever and writes some ridiculous 
code, like a recursive value list.  Then he'll be told to cut that out, 
and life will go back to normal.

This argument feels to me like "let's snatch defeat from the jaws of 
victory."  For years, we thought it was impractical that we could unify 
values and references.  But we are now 95% of the way there! 
Substitutibility is a sound, intuitive generalization of `==` over both 
refs and values.

While we're on the subject of fantasy, let me call attention to another 
fantasy that we've been engaging in: that somehow values can remain this 
"weird, off-to-the-side thing."  In Q-world they were -- and when you 
were writing code, you always had to be aware of whether you were 
dealing with values or objects (and generic code had to learn new rules 
because they might be dealing with either.) But that's not the world 
we've built (thankfully!)  Here, values will be a common, every day 
occurrence (Optional, LocalDateTime) that all Java code will have to 
deal with.  (They're Objects!)  We have to give people a sound, 
intuitive model for dealing with the union of refs and values, because 
they're going to have to deal with that.  And we're almost there, as 
long as we don't blow it.

I realize that we started out hyper-focused on the performance aspects 
(because there'd be no point in doing values in the first place if we 
didn't care about performance.)  But, users will not thank us if we 
routinely choose confusing semantics because its faster.  Now it's time 
to focus on delivering a programming model that makes users say "why 
didn't you do that 20 years ago" -- and we can do that. This is winning; 
let's take it.