On Dec 15, 2021, at 12:17 PM, Brian Goetz <brian.go...@oracle.com<mailto:brian.go...@oracle.com>> wrote:
The main problem I think we can't escape is that we'll still need some word that means only the eight predefined types. (For the sake of argument let's assume we can pick one and lean hard on it, whether that's "predefined", "built-in", "elemental", "leaf type", or whatever.) I've been calling them the built-in primitives; we've test-driven other terms like "basic" primitives. Assume we'll agree on a term. Also, no matter how we try, they will be different from the extended primitives in some ways, such as: - Their reference companions have weird names (e.g., Integer); - They permit a seemingly circular declaration (i.e., the declaration of "class int" will use "int" in its representation); - They will be translated differently, because the VM has built-in carriers for I/J/F/D, whereas extended primitives will use the L and Q carriers; - There will probably be some special treatment in reflection for these eight types; Most of these are things about which we can say "OK, fine, these are historical warts." There may be others asymmetries too, that derive from compatibility constraints. As you say, the game is minimization. Yes, this is a good list. Add to it: - They are named with a lower-case keyword - They exclusively get to use special operators (for now) My high-level response to "primitive=one of 8 types" is that it may be giving the good name to, and drawing attention to, something that doesn't matter much. Sure, we'll need to specify a distinction for the purpose of the things on the list, but I don't think most programmers should really care whether the value they're working with belongs to one of the 8 special types or not. These especially don't matter: - Aliased reference type names: going forward, everybody should be saying `int.ref` instead - Circular declarations: less than 100 people in the world need to care about this (maybe exaggerating) - Weird JVM features: yes, but the JVM has lots of quirks, ergonomics are not the top priority And the operator limitation is not fundamental, certainly could be addressed in the future. So we're left with, for most Java programmers, a set of special types that get spelled with keywords and get some special behavior in the reflection API. My initial sense is that's not enough to put them in their own different-noun category. Meanwhile, if we can tell programmers "primitives have members/classes now, and libraries can define additional primitives", that can build on existing intuitions pretty well. For example, the primitive type/reference type duality still exists, and pretty much works the same. Asking them to do s/primitive type/value type/ in this context is its own Indiana Jones maneuver.
