On May 1, 2019, at 6:28 AM, Brian Goetz <brian.go...@oracle.com> wrote: > > Also, we’re conflating two separate questions here. > > 1. What does V? mean. In the proposed world, it is the union type of V and > Null, nothing more (alternately: V adjoined with null.). > > 2. What is the relationship between V and V? — is it sub typing, or > conversion? > > I think Remi is more interested in (2), but you keep saying “it should be a > box”,w which suggests we’re not on the same page with respect to (1) either, > yet.
As you folks saw, I wrote a separate note that tries to explain the difference between legacy L-types and the new requirements of value (and template) types. Our best way so far to "shake the box" of language features is to have native int-like values of class V be declared with the plain syntax "V". These values need a new contract which is incompatible with the old contract for the JVM's references, so to access the old reference behavior we need a different syntax, and (so far) that seems to be V?. But let's not let ourselves be blinded by syntax. The term V?, if it is to mean "a reference under the old contract", cannot mean only "the values of V plus null". It also has to mean "extra indirections" and "no loading side effects when used" and probably also "can participate in circular definitions", as well "unconditionally accepts null". A language feature which only adjoins null doesn't pull its weight. We are adding V? because it also pulls the weight of the old contract, allowing backward compatibility with the JVM's references. But since those references are a permanent part of the JVM's *future*, it is also *future* compatibility with code which selects the old contract instead of the new. I suggest the following thought experiment: In our discussions of "what does V? mean", temporarily replace "V?" with "V*", read according to the norms of the C language. It will more accurately reflect the underlying "physics" of the JVM. — John
