Okay, let's stick a pin in proper-value-types (i.e. try to leave them out of this discussion) for a moment...
One question is whether the existing design for the bifurcated type hierarchy will carry right over to this split instead. (My understanding of that design is: every (non-Object) concrete class will implement exactly one of two disjoint interfaces, explicitly or not.) My first thoughts were that the situation is different here: exposed identity seems to be strictly (maybe?) contractually stronger than no exposed identity. So here, a class being "noncommittal" *ought to* look the same as it being identityless. In theory, it should be harmless for an identity class to extend an identityless class (while the opposite direction is a problem). So, first, is that even right? Next, even if so, the Backward Default Problem strikes again. To make a class identityless you would seem to need all your *supertypes* to be, first! That's hard to pull off. And `Object` itself would seem to want to be marked identityless, which is obviously weird/problematic. So I think we are forced back to a tripartite model (somewhat like we are having to do with nullness, but probably closer to what we'll have to do after nullness for `@OkayToIgnoreReturnValue`). "intentionally identityful" is-stronger-than "intentionally identityless" is-stronger-than "unknown so will be *presumed* identityful unless otherwise specified" It's possible that would put us straight back to where this email started. But this all smells rotten, like it demands we find a simpler way to think about it (which you may already know, and I'm just missing it so far). -- Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
