> On Jun 17, 2020, at 4:30 PM, Kevin Bourrillion <[email protected]> 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).
