I think what is missing from our presentation — and likely key to succeeding — is how to describe “compound value” in a way that feels like a thing.
Well, a `double` is already a compound value that feels like a thing. Java just hides the internal structure instead of having us access d.exponent directly etc. Is that a useful angle? I'm not sure, but right now I think it is. I wish I could be compelled by that argument (and I tried), but I can’t be. I think if we asked 1M Java developers, pretty much all of them would say something like “double is a primitive 64 bit value”. Yes, long and double have been allowed to tear forever, but (a) implementations have delivered 64 bit atomicity for almost forever, (b) most users don’t use long or double nearly as often as they use int, and (c) tearing is some weird concurrency black voodoo magic that people don’t want to pay attention to. The upshot is that I suspect that only 0.001% of developers have actually spent any significant amount of time thinking about long and double tearing, let alone encountered it in the wild. I don’t think we get away with “well, that could have happened with long, too.” It gets worse when compound values “code like a class”, because they have constructors, and constructors exist to establish invariants. It gets worse when we realize the only lesson of JCiP that most developers have internalized is “immutable classes are thread-safe.” Having a weird new tearing behavior from immutable classes will be astonishing. (One of the reasons to not allow capture of mutable locals back in the Lambda days was that would subject locals to data races — invalidating one of the few “free safe concurrency” guarantees we had.) So I think we have to confront the tearing beast head on.
