<div dir="ltr"><div>Am I understanding this correctly or are we throwing an idea out there?  Is the following legal today in Java 21?<br></div><div><br></div><div>
<font size="4" face="monospace">    switch (o) { <br>
              case Optional.of(var e): ...<br>
              case Optional.empty(): ...<br>
          }</font>

</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 26, 2024 at 6:28 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
  <div>
    <font size="4" face="monospace">Let's step back, because your
      question is caught up in the details of a solution, rather than
      focusing on the problem.<br>
      <br>
      Obviously we want to be able to pattern match on Optional.  You've
      gone down the road of "We have pattern matching for ADTs, so let's
      turn Optional into an ADT, and then pattern match on that", and
      then got caught in the details of whether this is a compatible
      refactoring.<br>
      <br>
      But I don't think we have to, or should, refactor the
      representation to "match" the pattern machinery.  As outlined in
      "Towards Member Patterns" and "Patterns in the Object Model", we
      want to use the same tools for destructuring as we do for
      aggregation.  Optional is assembled with static factories; we
      should be able to take it apart with static patterns:<br>
      <br>
          switch (o) { <br>
              case Optional.of(var e): ...<br>
              case Optional.empty(): ...<br>
          }<br>
      <br>
      Adding `Some` and `None` deconstruction patterns would work, but
      then we lose the correspondence between "how we put it together"
      and "how we take it apart."  So I don't want to go down this
      road.  (Another reason to not go down this road is that we want
      Optional to work as a value type, which means one
      implementation.)  <br>
      <br>
      There are a few details yet to be wrapped up (e.g., how do we
      denote the of/empty pair as exhaustive).<br>
    </font><br>
    <div>On 1/26/2024 2:30 AM, Red IO wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="auto">Now that pattern matching is nearly complete I was
        thinking about the distinction how the option type of the jdk
        works.
        <div dir="auto">What I'm talking about is the split between
          checking if it's empty and retrieving the value.</div>
        <div dir="auto">Sure there are ways to transform the optional
          and GetOrElse and Throw varients. But none of them express the
          connection between isPresent and get:</div>
        <div dir="auto">var option = Optional.of("Foo");</div>
        <div dir="auto">if (option.isPresent()) {</div>
        <div dir="auto"><span style="white-space:pre-wrap">     </span>var foo =
          option.get(); </div>
        <div dir="auto">} </div>
        <div dir="auto">Now pattern matching comes into play. A great
          solution that is used by many other languages to deal with the
          option type is matching rather or not it's present and in the
          same step providing the value to the valid code block.
          Something like this:</div>
        <div dir="auto">var option = Optional.of("Foo");</div>
        <div dir="auto">switch(option) {</div>
        <div dir="auto"><span style="white-space:pre-wrap">     </span>case
          Some(foo) -> {} </div>
        <div dir="auto"><span style="white-space:pre-wrap">     </span>case
          None() -> {} </div>
        <div dir="auto">} </div>
        <div dir="auto">Or </div>
        <div dir="auto">if(option instanceof Some(foo) {</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">} </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">This is indeed possible in the current version
          of java using sealed types, records and pattern matching.</div>
        <div dir="auto">Now it's sad that Optional was introduced before
          the features we have now where available and introducing a
          second option type would be confusing and terrible for apis.</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">But I don't think all hope is lost yet. I'm not
          too familiar with binary compatibility but from an api
          standpoint it would not change the public api of optional if
          it was turned from a final class into a sealed interface with
          2 inner records representing the 2 states of the Optional
          instead of a nullable field. This way the public api of
          optional would just be added 2 inner types and otherwise stay
          the same. </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">I would love to hear your feedback on this one.</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Great regards </div>
        <div dir="auto">RedIODev </div>
      </div>
    </blockquote>
    <br>
  </div>

</blockquote></div>