<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <br>
    <br>
    <o:p> </o:p>
    <blockquote type="cite" cite="mid:AS1PR01MB922896A0D3894066ACF1F98CD3DE9@AS1PR01MB9228.eurprd01.prod.exchangelabs.com">
      <div class="WordSection1">
        <div>
          <pre>I asked a whether the following would be legal in an earlier email.</pre>
          <pre>The draft now explains that it is, but I still wonder what this snippet</pre>
          <pre>would get desugared to.</pre>
          <pre><o:p> </o:p></pre>
          <pre>```</pre>
          <pre>Number num = ...;</pre>
          <pre><o:p> </o:p></pre>
          <pre>if (num instanceof byte b) {</pre>
          <pre>    ...</pre>
          <pre>}</pre>
          <pre>```</pre>
        </div>
      </div>
    </blockquote>
    <br>
    There are many choices of what the compiler could do.  If I had to
    guess, the most likely is an invocation of a library method like:<br>
    <br>
        static boolean isSafeToCastFromIntToByte(n) { ... }<br>
    <br>
    followed by a cast to byte with `I2B` if this method returns true. 
    This models the translation of the corresponding idiom with
    reference types; first check if the cast is safe with `INSTANCEOF`
    (which pushes a boolean on the stack), and then if that succeeds,
    use `CHECKCAST` to perform the casting.  Of course, the compiler
    could do the domain check inline as well; this is an implementation
    detail that the compiler has some latitude over.  Obviously there's
    also some latitude over where to put such helper methods and what to
    call them (as they may also be useful to other code, possibly
    because they capture snippets of language semantics that can be
    reused as as a method reference or method handle.)<br>
    <br>
    <blockquote type="cite" cite="mid:AS1PR01MB922896A0D3894066ACF1F98CD3DE9@AS1PR01MB9228.eurprd01.prod.exchangelabs.com">
      <div class="WordSection1">
        <div>
          <pre><o:p>
</o:p></pre>
          <pre>>><i> I agree that revisiting concepts is something we have to do, but breaking the difference between subtyping and primitive conversions for a corner case, in isolation, is a decision hard to understand.<o:p></o:p></i></pre>
          <pre>><i><o:p> </o:p></i></pre>
          <pre>><i> First, a subtyping relationship for primitives does exist, though it doesn’t cover all of the possible conversions.<o:p></o:p></i></pre>
          <pre>Second, nothing is broken, shattered, or wrecked even in cases subtyping doesn’t exist, because the draft doesn’t propose to *change* the meaning of patterns, but rather to generalise them. I.e. its insight is that subtyping is a special case of assignment conversion, and so patterns are “really” about the validity of such conversions rather than about the specific case of subtyping.</pre>
          <pre><o:p> </o:p></pre>
          <pre>I had a quick look over the spec and I couldn't find any place that</pre>
          <pre>actually used the subtyping relation between primitives. The case</pre>
          <pre>you seem to be claiming widening primitive conversion matches 100%</pre>
          <pre>with the rules about subtyping, it actually doesn't use subtyping</pre>
          <pre>at all and just lists all possible conversions.</pre>
        </div>
      </div>
    </blockquote>
    <br>
    I don't think Ron is claiming that; the bit about "Well, there
    actually is subtyping here" was offered to rebut a spurious claim to
    the contrary.  But I don't think this is that important; whether int
    <: long or not is not that relevant to the language (personally I
    think the spec would be better without trying to define subtyping on
    primitives, for exactly the sorts of confusions that have come up in
    this thread, such as covariant overrides), and primitive widening
    conversions do not align with subtyping (because some widenings are
    not unconditionally exact.)  <br>
    <br>
    But, all of this is a distraction.  The question is whether the
    sorts of unsafety you get from casting between reference types (it
    might throw NPE) and the sorts of unsafety you get from casting
    between primitives (it might succeed but give you a garbage value)
    are so radically different that attempting to unify them under the
    same rubric (check instanceof before you cast) is some sort of
    Lovecraftian horror.  The reality is, we have gotten used to them
    being separate, but they're not really that different.  <br>
    <o:p> </o:p>
    <blockquote type="cite" cite="mid:AS1PR01MB922896A0D3894066ACF1F98CD3DE9@AS1PR01MB9228.eurprd01.prod.exchangelabs.com">
      <div class="WordSection1">
        <div>
          <pre>A interesting question that could be asked is:</pre>
          <pre>"What does subtype/supertype mean". Although it is used in the spec</pre>
          <pre>it isn't really explain apart from being a reflexive and transitive</pre>
          <pre>relationship between types.</pre>
        </div>
      </div>
    </blockquote>
    <br>
    And if you pull on this string some more, you get to "what do types
    really mean."  Which is an excellent philosophical question, one
    which has been studied extensively with multiple overlapping
    theories (e.g., intensional vs extensional) that are useful in
    different situations.  Sometimes it is useful to think of types as
    sets of values, where subtyping is mere subsetting; in other
    situations, it is useful to think of them as objects in a category. 
    <br>
    <br>
    But if you do pull on this string, you realize that it does not
    really offer much of an answer here, because people form their own
    theories about what types and subtyping are (which can be useful!)
    -- and then some language designer comes along and invalidates those
    personal theories by evolving the language in a way the theory
    didn't anticipate.  And this is where the strong emotional reaction
    of "but THATS not what instanceof (or whatever) means" comes from,
    which is mostly what we're dealing with here.  <br>
    <br>
    And, I realize as a language designer, one of the things I should be
    aware of is how much we are asking users to change their mental
    models.  And this too is a balance; making the language more
    expressive or consistent always risks stepping on someone's mental
    model.  We do ask ourselves "how much will this freak people out"
    (and sometimes the answer is "way too much, we can't do that"), but
    this is but one input into the balance.<br>
    <br>
    <br>
    <blockquote type="cite" cite="mid:AS1PR01MB922896A0D3894066ACF1F98CD3DE9@AS1PR01MB9228.eurprd01.prod.exchangelabs.com">
      <div class="WordSection1">
        <div>
          <pre>A few of the emails argue that we should see `instanceof` as a</pre>
          <pre>safe cast check, not like an "inheritance" check or</pre>
          <pre>a "reference subtype" check. If the operator was called</pre>
          <pre>`canbesafelyconvertedto` I might agree, but thats not the case.</pre>
        </div>
      </div>
    </blockquote>
    <br>
    Yes, past syntax decisions affect our mental models, and sometimes a
    past choice is so constraining that there is no room to extend an
    existing syntax, but this is surely a subjective business.  But I
    agree with you that this is at the heart of the most significant
    negative reactions to this JEP -- people have associated specific
    and personal feelings about the meaning of the term "instanceof". 
    But we have to realize these are personal associations, and while
    they may work for us, we should be aware that these are our own
    personal associations.<br>
    <o:p> <br>
    </o:p>
    <blockquote type="cite" cite="mid:AS1PR01MB922896A0D3894066ACF1F98CD3DE9@AS1PR01MB9228.eurprd01.prod.exchangelabs.com">
      <div class="WordSection1">
        <div>
          <pre>Now this might seem I'm arguing in favour of `instanceof byte`.</pre>
          <pre>And on it's own that might look correct, but then you have</pre>
          <pre>justify the fact that the integer values/instances between -128</pre>
          <pre>and 127 and the byte values/instances are the same. In my mind</pre>
          <pre>the way this would be justified is by using the fact that `byte`</pre>
          <pre>is a subtype of `int` which is why it's set of instances is a</pre>
          <pre>subset of the instances of `int`. But this raises the issue</pre>
          <pre>that the set of instances of `int` can't be a subset of the set</pre>
          <pre>of instances of `float` cause not all ints are valid floats.</pre>
        </div>
      </div>
    </blockquote>
    <br>
    Again, you have developed a mental model of what a type is, and what
    instanceof means, that has been useful to you.  Yours is very much
    tied to subtyping, which is consistent with the current model. 
    Which is fine -- but it's just a mental model.  I think you'll find
    that after you get over the frustration of "the world changed",
    snapping to this generalization of instanceof won't actually be that
    hard.  Give it some time.<br>
    <br>
    <br>
  </body>
</html>