It looks like we're getting somewhere; thanks for the detailed response. I have one targeted reply:
On May 1, 2019, at 4:38 PM, [email protected] wrote: > > So let's call it V*. I want also make clear that there is no proposal to not > have a V*, we need it, and it's the L-version of an inline type for the VM. That would an ugly choice, for sure. But it's also a full disclosure of the presence of the indirection. … > It's not fine to use Integer as parameter of a method. There's one place where Integer is OK as a method parameter or return, and that is when you are reaching for null as a sentinel. I'm pretty sure I've written code like that. This, I think, is why V* is OK to spell as V?. My contribution to this conversation is to explain why, as one of Java's lumping-not-splitting design moves, we are adjoining the responsibilities of V* to the contract of V?. If V? were purely a value-set variant of V, then V* and V? would be distinct and subtly different types. But one of Java's super-powers is that it doesn't *do* that level of type refinement. — John
