<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4" face="monospace">It is not currently allowed, being
discussed on a-s-e. </font><br>
<br>
<div class="moz-cite-prefix">On 1/26/2024 11:17 AM, Nathan Reynolds
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CALMUwco0EYxSKCDWiWVGFLUHDV-ga=8d0V04MaB7wvHynO00cQ@mail.gmail.com">
<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" moz-do-not-send="true" class="moz-txt-link-freetext">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">
<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>
</blockquote>
<br>
</body>
</html>