<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Looks good, thanks</p>
    <p>Maurizio<br>
    </p>
    <div class="moz-cite-prefix">On 21/10/2019 13:02, Gavin Bierman
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:2D62B016-0B07-4D20-A5C8-7A432ADABC5C@oracle.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      Thanks Maurizio. I have tweaked the two definitions to be more
      clearly aligned.
      <div class=""><br class="">
      </div>
      <div class="">Gavin<br class="">
        <div><br class="">
          <blockquote type="cite" class="">
            <div class="">On 21 Oct 2019, at 10:57, Maurizio Cimadamore
              <<a href="mailto:maurizio.cimadamore@oracle.com"
                class="" moz-do-not-send="true">maurizio.cimadamore@oracle.com</a>>
              wrote:</div>
            <br class="Apple-interchange-newline">
            <div class="">
              <meta http-equiv="Content-Type" content="text/html;
                charset=UTF-8" class="">
              <div text="#000000" bgcolor="#FFFFFF" class="">
                <p class="">Hi Gavin,<br class="">
                  looks good, and I note that you also tweaked
                  instanceof to use a "bi-modal" semantics - e.g.
                  instanceof Type | Pattern.</p>
                <p class="">On that note, I find that the section which
                  speaks about 'type instance of' could use same cleanup
                  you did on patterns:</p>
                <p class="">"<br class="">
                </p>
                <p class="">If a cast of the <em class="">RelationalExpression</em>
                  to the <em class="">ReferenceType</em> would be
                  rejected as a compile-time error (<a
href="https://docs.oracle.com/javase/specs/jls/se11/html/jls-15.html#jls-15.16"
                    class="" moz-do-not-send="true">15.16</a>), then the
                  <code class="">instanceof</code> expression likewise
                  produces a compile-time error. In such a situation,
                  the result of the <code class="">instanceof</code>
                  expression could never be true.</p>
                <p class="">If the casting conversion of the <em
                    class="">RelationalExpression</em> to the <em
                    class="">ReferenceType</em> makes use of a narrowing
                  reference conversion which is unchecked (<a
href="https://docs.oracle.com/javase/specs/jls/se11/html/jls-5.html#jls-5.1.6.2"
                    class="" moz-do-not-send="true">5.1.6.2</a>), then a
                  compile-time error occurs.<br class="">
                  "<br class="">
                </p>
                <p class="">The text here looks a bit redundant, and
                  similar to what you had in the previous version of the
                  spec. Perhaps you could use same cleanups as what you
                  did in 14.30.2 (which, btw, looks great!)</p>
                <p class="">Maurizio<br class="">
                </p>
                <p class=""><br class="">
                </p>
                <div class="moz-cite-prefix">On 21/10/2019 10:50, Gavin
                  Bierman wrote:<br class="">
                </div>
                <blockquote type="cite"
                  cite="mid:2596DE6A-0154-488A-9EDC-031A6E300CF0@oracle.com"
                  class="">
                  <pre class="moz-quote-pre" wrap="">A second, and hopefully final, draft language spec for JEP 305 (Pattern matching for instanceof) is available at:

<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~gbierman/jep305/jep305-20191021/specs/patterns-instanceof-jls.html" moz-do-not-send="true">http://cr.openjdk.java.net/~gbierman/jep305/jep305-20191021/specs/patterns-instanceof-jls.html</a> <a class="moz-txt-link-rfc2396E" href="http://cr.openjdk.java.net/~gbierman/jep305/jep305-20191021/specs/patterns-instanceof-jls.html" moz-do-not-send="true"><http://cr.openjdk.java.net/~gbierman/jep305/jep305-20191021/specs/patterns-instanceof-jls.html></a>

Apart from a small number of minor corrections, the two main changes are:

1. We are relaxing the conditions around the typing of the instanceof operator, as discussed on the EG list a little while ago. The second operand is no longer required to be a reifiable type, but we require the type of the expression can be convertible to the type by casting conversion, and that casting conversion does not make use of an unchecked narrowing reference conversion.

2. The specification for patterns will not now appear in a new chapter, but in a new section 14.30. (Sections 14.22-14.29 will remain unused for now, to allow for further language evolution.)

As always, please email me any comments/thoughts/bugs.

Thanks,
Gavin

</pre>
                  <blockquote type="cite" class="">
                    <pre class="moz-quote-pre" wrap="">On 19 Sep 2019, at 10:28, Gavin Bierman <a class="moz-txt-link-rfc2396E" href="mailto:gavin.bierman@oracle.com" moz-do-not-send="true"><gavin.bierman@oracle.com></a> wrote:

A draft language spec for JEP 305 (Pattern Matching for instanceof) is available at:

<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~gbierman/jep305/jep305-20190918/specs/patterns-instanceof-jls.html" moz-do-not-send="true">http://cr.openjdk.java.net/~gbierman/jep305/jep305-20190918/specs/patterns-instanceof-jls.html</a> <a class="moz-txt-link-rfc2396E" href="http://cr.openjdk.java.net/~gbierman/jep305/jep305-20190918/specs/patterns-instanceof-jls.html" moz-do-not-send="true"><http://cr.openjdk.java.net/~gbierman/jep305/jep305-20190918/specs/patterns-instanceof-jls.html></a>

Comments are welcomed on all aspects, but I draw your attention to a couple of things that we’d like your feedback on:

1. The instanceof operator restricts the type to be a reifiable reference type. The spec currently keeps that restriction for type test patterns too. But should we go further, i.e. will people expect to be able to say the following (given that this *declares* a pattern variable l)?

if (o instanceof List<Integer> l) {
 …


2. We’d like to keep the possibility open for merging of multiple pattern declarations, where it makes sense. For example:

if (a instanceof Foo f || b instanceof Foo f) {
… // Like to be able to use f here


The current spec explicitly calls out cases like these as compile-time errors, to allow for forwards compatibility if we add this feature. But what do you think of this feature? (We have textually multiple declarations of a pattern variable, but they are “merged”, so they are really the same thing…)

3. [Only for spec nerds] I am proposing to add a new Chapter 16 to discuss patterns (at the moment it’s short, but we’re planning for it to grow). The existing Chapters 16-19 will be renumbered to 17-20. Will this renumbering cause problems for anyone?


Thanks,
Gavin
</pre>
                  </blockquote>
                </blockquote>
              </div>
            </div>
          </blockquote>
        </div>
        <br class="">
      </div>
    </blockquote>
  </body>
</html>