<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div dir="auto" style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
[The following is only of interest to those concerned about very fine details of the JLS; no change to the language is proposed here.]
<div><br>
</div>
<div>Currently in the JLS we build the mechanics of pattern matching directly on top of casts. For example, in 14.30.2 (emphasis added):</div>
<div><br>
</div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>- A value v that is not the null reference matches a type pattern of type T if v **can be cast to** T without raising a ClassCastException; and does not match otherwise.</div>
<div><br>
</div>
<div>This was useful as it made real the equivalence:</div>
<div><br>
</div>
<div><font face="Courier New"><b>if</b> (e <b>instanceof</b> T t) { … } <—> <b>if</b> (e
<b>instanceof</b> T) { T t = (T)e; …} </font></div>
<div><br>
</div>
<div>But, in terms of the JLS, there are some shortcomings. First, the semantics of pattern matching above should really refer to casting _conversions_ rather than casts. Oh well. But digging a little deeper there are further issues. Section 5.5 defines cast
_contexts_ - the places where cast conversions can be applied. Except that it is all a little misleading. It currently says "Casting contexts allow the operand of a cast expression (15.16) to be converted to the type explicitly named by the cast operator.”
but that’s not really true as we just agreed that we want to cover the new pattern matching contexts too. Sigh. It also gets complicated by the fact that we don’t want to use all the cast conversions either - we exclude any narrowing reference conversions
that are unchecked AND we actually don’t use any of the cast conversions that deal with primitive types (these are all excluded by the definition of “applicability” of patterns). We deal with this by introducing the concept of "checked cast convertible" in
5.5 and relying on the fact that we only consider applicable patterns. </div>
<div><br>
</div>
<div>This is all okay, but with the changes proposed by JEP 455 (Primitive types in patterns, instanceof, and switch) coming real soon now, it is time to tidy up this treatment and set a proper foundation. </div>
<div><br>
</div>
<div>To this end, we propose to add a new, seventh sort of context to the list given in the introduction to chapter 5 - called *testing contexts* - to handle pattern matching, and also define a notion of *test conversion*. As an example, the rule from the semantics
of pattern matching given above, can now be expressed as:</div>
<div><br>
</div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>- A value v that is not the null reference matches a type pattern of type T if v can be converted by testing conversion to the target type T without raising a ClassCastException; and does not
match otherwise.</div>
<div><br>
</div>
<div>I have made a spec change document so you can see the details of this change that will appear in the Java SE 22 Edition of the spec:</div>
<div><br>
</div>
<div><a href="https://cr.openjdk.org/~gbierman/new-context/specs/new-context.html">https://cr.openjdk.org/~gbierman/new-context/specs/new-context.html</a><br>
</div>
<div><br>
</div>
<div>Again, I repeat, this is purely a presentational change at the level of the spec - the Java language itself is unchanged. </div>
<div><br>
</div>
<div>Thanks,</div>
<div>Gavin</div>
</div>
</body>
</html>