We have to talk about "primitive".

[Brian Goetz]

> Background: the textbook definition of "primitive" is centered on 
> their nature of being elements-not-molecules, and I see no dispute 
> about it. Also, there's no disputing the fact that we're allowed to 
> adopt a different meaning if we so choose. So that's not even the 
> fatal flaw.

Yes, that's definitely a point against -- these things are "not 
primitive" in the atomic sense.  OTOH, they are *very much like* today's 
primitives in many other ways.  So this is a choice between being 
strictly linguistically accurate and appealing to existing mental 
models.  Tough choice.

> 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.

> An alternative that seems to work fine, in my mental model at least, is:
>
>   * Primitive types are examples of value types, and have always been.
>   * Java never supported any other kinds of value types before, so we
>     didn't distinguish the terms before.
>   * Everything you associate with primitive types remains true.
>   * But most of those traits really come from their value-type-ness.
>

FTR, there is one big difference, which has a few consequences.  The big 
difference is reference-ness; value and primitive classes give rise to 
reference types, whereas primitive classes additionally give rise to a 
"primitive" type.  That the "primitive" type gives us reference-ness 
means it gives up nullability and non-tearability.

I think what you're saying here, at root, is to give the "value" name to 
extended primitives, and find another name to give to B2?