<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Oh, I understand where you are coming from. Being able to capture completion assertions, and have them be type checked at compile time (and backed up by runtime tests at run time, if necessary) is a “happy clean” feeling. Which is why we see it as a “stretch”
goal for member patterns. But we are also mindful of the diminishing returns, where the incremental benefit falls short of the incremental complexity. So this is still up in the air.
<div class=""><br class="">
</div>
<div class="">Note that we already do throw MatchException when a synthetic default is triggered. This can happen when you have an enum or sealed class and it acquires another constant/subtype, and the code with the switch is not recompiled. Then the synthetic
default becomes reachable, and to avoid hazards like switch expressions not having a value, ME is thrown. <br class="">
<div class="">
<div class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Jun 3, 2024, at 1:30 PM, Olexandr Rotan <<a href="mailto:rotanolexandr842@gmail.com" class="">rotanolexandr842@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">Yes, I am in fact talking about exhaustiveness (and possibly patterns hierarchy that I have talked about initially). The "set of states" is just a nominal aggregation of such patterns. I believe that in most cases, patterns are aggregated by
some feature (state of async op, state of stream, empty/non-empty optional etc), this is just a possible way to let the language know this information too for some purpose. I do believe that syntax like switch (...) over SetOfStates is good for readability
in case there are many groups of patterns for the same type as the code. Also, it allows to isolate group of patterns that represent subject area one is switching over from any other patterns, wo there are no situations, where programmer could think "Well,
I checked if it matches 3 patterns from area A, now lets see if it matches something from area B", which is kind of mixing apples and hippos and is simply incorrect way to write code.
<div class=""><br class="">
</div>
<div class="">Now to the elephant in the room: exhaustiveness. I understand your concerns about a whole world of places where error can occur, if you just let users assert that set of states is exhaustive. On the other hand, I think you also understand how
much value this could bring for readability, code structuring and exhaustiveness. So my opinion on whether the option to assert exhaustiveness should exist or not: I really don't know. There could be some herbivore compromises like throwing IllegalStateException
in the synthetic default branch, which both fits semantically and kind of solves the problem, but this is still a compromise. This is kind of a double-edged blade here and having things like that is not in Java's fashion. Although,throwing an exception in
case of incorrect assertion is too high a price to pay to discard this feature completely, sacrificing enhanced readability, structuring and exhaustiveness? I think this is up to you as language designers to decide. I, as a regular user, would say that I would
be willing to pay that price if I had the option to. It is also a unique feature to have, a selling point of Java in some sense.<br class="">
<br class="">
Also, maybe it is just me, but this switch over syntax seems just really neat and being really descriptive about what this switch statement/expression is responsible for.</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Jun 3, 2024 at 7:20 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" class="">brian.goetz@oracle.com</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="overflow-wrap: break-word;" class=""><br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">If I understand correctly, member patterns are a way to say "I declare a, possibly exhaustive, set of states that class that patterns are members of could take". This is a good thing obviously, but this only works if one has access to source code
of the class one wants to declare states of.</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">To be more precise, using your terminology:</div>
<div class=""><br class="">
</div>
<div class=""> - A _deconstruction pattern_ declares a state that all instances of the current class must be in. (This derives from deconstruction patterns being total.)</div>
<div class=""> - An _instance pattern_ declares a state that some instances of the current class can be in. Under the proposed “case pattern” approach, a set of such patterns can indicate that they cover all instances of the class.</div>
<div class=""> - A _static pattern_ declares a state that some instances of _some other_ class can be in. Same story about “case pattern”, though it is far more likely people will make incorrect assumptions / implementations about exhaustiveness when they
are working at arms length. </div>
<div class=""><br class="">
</div>
<div class="">So I believe that what you want is handled by static patterns, optionally augmented with some mechanism for exhaustiveness. </div>
<div class=""><br class="">
</div>
<div class="">I suspect that you are more interested in the exhaustiveness part than the static pattern part, but I think there are diminishing returns there. Any statement of “this set of patterns is exhaustive” is not trustable, so the compiler always has
to insert a synthetic default anyway. </div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class=""><br class="">
</div>
<div class="">What am I asking for / suggesting, is to also add the possibility to declare such set of states for external classes. More formally, I want to be able to state something like "I declare a set of states X that type Y could take in the subject area
Z, that could be exhaustive if asserted". Using an example with tokes, I could reformulate this as follows: "I declare a set of states TokenKinds that type String could take in the subject area "Tokens", that is exhaustive by assertion". Subject area is not
something present in language semantics, more of a topic that unites this set of states. Applying to CompletableFuture, this feature could introduce something like:<br class="">
<br class="">
switch (future) over AsyncStates {</div>
<div class="">case Completed(var result) -> ...<br class="">
case Interrupted -> ...<br class="">
case Failed(var ex) -> ...<br class="">
</div>
<div class="">}<br class="">
<br class="">
Note that "over AsyncStates" asserts that only patterns from set of states AsyncStates could be present</div>
<div class=""><br class="">
</div>
<div class="">This could help adapt existing APIs to new java paradigms and features without having to modify them directly, which is in many cases at least unpleasant. Also, this opens a world of possibilities for users, by enabling them to use custom patterns
on types they cant access source code of. Not limited to the Java standard library, It could be also useful in frameworks, with tasks like checking if principal is anonymous/logged in/unauthorized, and a huge pile of other ways that people could apply this
feature.</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Apr 29, 2024 at 6:27 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank" class="">brian.goetz@oracle.com</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br class="">
<br class="">
On 4/29/2024 10:02 AM, Olexandr Rotan wrote:<br class="">
> I think I did a really poor job expressing my thoughts in the first <br class="">
> message. I will try to be more clear now, along with some situations I <br class="">
> have encountered myself.<br class="">
><br class="">
> Assume we have a stateless math expressions parser. For simplicity, <br class="">
> let's assume that we split expressions into several types: <br class="">
> "computation-heavy", "computation-lightweight", "erroneous" (permits <br class="">
> null as input) and "computation-remote" (delegate parsing to another <br class="">
> service via some communication protocol), and types can be assigned <br class="">
> heuristically (speculatively). For some tasks, we need to perform some <br class="">
> pre- and postprocessing around core parsing logic, like result <br class="">
> caching, wrapping parsing into virtual thread and registering it in <br class="">
> phaser etc., for others - log warning or error, or fail parsing with <br class="">
> exception.<br class="">
<br class="">
If you are envisioning side-effects, then I think you are already <br class="">
abusing patterns. Patterns either match, or they don't, and if they do, <br class="">
they may produce bindings to describe witnesses to the match. Exceptions <br class="">
are not available to you as a normal means of "something went wrong"; in <br class="">
writing patterns (you should think of throwing an exception from a <br class="">
pattern declaration as being only a few percent less drastic than <br class="">
calling System.exit()).<br class="">
<br class="">
Patterns, as explained in the various writeups, are the dual <br class="">
(deconstruction) of certain methods (aggregations.) I don't see the <br class="">
duality here. (If I had to guess, you're trying to bootstrap your way <br class="">
to parser combinators with patterns, but that's a different feature.) <br class="">
So I'm still not sure that you're using patterns right, so I still want <br class="">
to focus on that before we start inventing new features.<br class="">
<br class="">
Case patterns are a form of ad-hoc exhaustiveness, to be used only when <br class="">
other sources of exhaustiveness (e.g., enums, sealed types, ADTs) fail. <br class="">
It isn't clear to me yet that these other sources have failed.<br class="">
<br class="">
<br class="">
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</body>
</html>