[External] : Re: Reviewing feedback on patterns in switch

[forax at univ-mlv.fr]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Sent: Wednesday, February 16, 2022 3:57:39 PM
> Subject: Re: [External] : Re: Reviewing feedback on patterns in switch

> OK, I'll make you a deal: I'll answer your question about let/bind, under the
> condition that we not divert the discussion on that right now -- there'll be a
> proper writeup soon. The answer here is entirely for context.

> If you don't agree, stop reading now :)
I think it's wiser to delay the discussion about let for later :) 

Rémi 

> On 2/15/2022 5:58 PM, Remi Forax wrote:

>>> - There are future constructs that may take patterns, and may (or may not) want
>>> to express guard-like behavior, such as `let` statements (e.g., let .. when ..
>>> else.) Expressing guards here with && is even less evocative of "guard
>>> condition" than it is with switches.
>> It's not clear to me how to use "let when else". Is it more like a ?: in C than
>> the let in in Caml ?

> The simplest form of `let` is a statement that takes a total pattern:

> let Point(var x, var y) = aPoint;

> and introduces bindings x and y into the remainder of the block. When
> applicable, this is better than a conditional context because (a) you get type
> checking for totality, and (b) you don't indent the rest of your method inside
> a test that you know will always succeed.

> If the pattern is total but has some remainder, the construct must throw on the
> remainder, to preserve the invariant that when a `let` statement completes
> normally, all bindings are DA.

> What if I want to use a partial pattern, and then customize either the throwing
> part or provide default values? I can provide an else clause:

> Object o = ...
> let String s = o
> else throw new NotStringException();

> or

> Object o = ...
> let String s = o
> else { s = "no string"; }

> These are two ways to preserve the "DA on normal completion" invariant; either
> by not completing normally, or by ensuring the bindings are DA.

> Now, we are in a situation where we are with switch: patterns do not express all
> possible conditions. Which is why we introduced guards to switches. And we can
> use the same trick here:

> Object o = ...
> let String s = o
> when (!s.isEmpty())
> else { s = "no string"; }

> If we tried to use && here, it would look like

> Object o = ...
> let String s = o && (!s.isEmpty())
> else { s = "no string"; }

> which has the same problem as `case false && false`.

> Reminder: THIS EXPLANATION WAS PROVIDED SOLELY TO CLARIFY THE "FUTURE CONSTRUCT"
> COMMENT IN THE && DISCUSSION.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220216/a2781ef5/attachment-0001.htm>