Evolving the wrapper classes

[Dan Smith]

> On Jun 17, 2020, at 4:30 PM, Kevin Bourrillion <kevinb at google.com> wrote:
> 
>> - The type 'Integer.val' is equivalent to 'int'. Primitive types are inline types—they have members, support method invocation, etc.
>> 
> This at least suggests that `42L.hashCode()` would begin to work just as `"foo".hashCode()` does?

Yep, that's what I mean. Member accesses are now allowed (assuming the member you're looking for exists) for all types.

> Users can write `Integer.val` in their code, but would there ever be a good reason to? I assume we would always prefer `int`. And this actually makes me wonder if it's worth considering also allowing `int.ref` to be an alias for `Integer` because it would allow users to drop the word `Integer` from their code more completely, and therefore `int` would look more and more like it was just an inline type like any other. It reminds you that the old boxing/unboxing isn't in play anymore. And `int.ref` is more self-evidently something you can't synchronize on, etc. But, what would remain weird is that you don't actually find a val-default class called `int` sitting in an `int.java` file.

Agreed, I think it would be reasonable to consider both i) supporting 'int.ref' as type syntax, and ii) prohibiting 'Integer.val'.

Although, redundancies aside, if you have some discomfort with bare 'Integer' being a reference type for an inline class, you may have similar discomfort with our "reference default" story in general (e.g., 'LocalDateTime' will have the same properties).