> On Feb 16, 2022, at 9:57 AM, Brian Goetz wrote:
> . . .
> 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
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Wednesday, February 16, 2022 5:03:19 PM
> Subject: Re: [External] : Re: Reviewing feedback on patterns in switch
> Of course, in an ecosystem as diverse as Java develope
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> 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 questi
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Wednesday, February 16, 2022 3:48:14 PM
> Subject: Re: [External] : Re: Reviewing feedback on patterns in switch
>> Not sure it's a no-brainer.
>> The
On 2022-02-16T10:49:19 -0500
Brian Goetz wrote:
> One thing that we have, perhaps surprisingly, *not* gotten feedback on
> is forcing all non-legacy switches (legacy type, legacy labels,
> statement only) to be exhaustive. I would have thought people would
> complain about pattern switches
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Wednesday, February 16, 2022 4:49:19 PM
> Subject: Re: Reviewing feedback on patterns in switch
> One thing that we have, perhaps surprisingly, *not* gotten feedback on is
> forcing all non-legac
> From: "Brian Goetz"
> To: "Guy Steele" , "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Wednesday, February 16, 2022 4:05:35 PM
> Subject: Re: Reviewing feedback on patterns in switch
>>> For me, && is more natural
, the best we can do is noisy
warnings.)
On 2/16/2022 11:00 AM, Remi Forax wrote:
*From: *"Brian Goetz"
*To: *"amber-spec-experts"
*Sent: *Wednesday, February 16, 2022 4:49:19 PM
*Su
One thing that we have, perhaps surprisingly, *not* gotten feedback on
is forcing all non-legacy switches (legacy type, legacy labels,
statement only) to be exhaustive. I would have thought people would
complain about pattern switches needing to be exhaustive, but no one
has! So either no one
For me, && is more natural than "when" because i've written more
switch that uses && than "when".
And don't forget that unlike most of the code, with pattern matching
the number of characters does matter, this is more similar to
lambdas, if what you write is too verbose, you will not write
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 :)
On 2/15/2022 5:58 PM, Remi Forax
Not sure it's a no-brainer.
The question is more a question of consistency. There are two
consistencies and we have to choose one, either switch never allows
null by default and users have to opt-in with case null or we want
patterns to behave the same way if they are declared at top-level
bruary 15, 2022 7:50:06 PM
Subject: Re: Reviewing feedback on patterns in switch
We're preparing a third preview of type patterns in switch. Normally we would
release after a second preview, but (a) we're about to get record patterns,
which may disclose additional issues with switch, so best to ke
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Tuesday, February 15, 2022 7:50:06 PM
> Subject: Re: Reviewing feedback on patterns in switch
> We're preparing a third preview of type patterns in switch. Normally we would
> release after a seco
We're preparing a third preview of type patterns in switch. Normally we
would release after a second preview, but (a) we're about to get record
patterns, which may disclose additional issues with switch, so best to
keep it open for at least another round, and (b) we're proposing some
You can say you only change the semantics of switch not the semantics
of pattern matching, but the idea that you can separate the two is
confusing.
From a mathematical point of view, it is quite clear. We define a `x
matches P` relation. In this relation, `Object o` matches all values of
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "Tagir Valeev" , "amber-spec-experts"
>
> Sent: Thursday, January 27, 2022 4:41:27 PM
> Subject: Re: [External] : Re: Treatment of total patterns (was: Reviewing
> feedback on pattern
- Original Message -
> From: "mark"
> To: "Brian Goetz"
> Cc: "amber-spec-experts"
> Sent: Friday, January 28, 2022 12:43:55 PM
> Subject: Re: Reviewing feedback on patterns in switch
> On 2022-01-25T19:46:09 +
> Brian Goetz wrot
On 2022-01-25T19:46:09 +
Brian Goetz wrote:
> We’ve previewed patterns in switch for two rounds, and have received some
> feedback. Overall, things work quite well, but there were a few items which
> received some nontrivial feedback, and I’m prepared to suggest some changes
> based on
In that case, i prefer the current semantics because it's the same if a pattern
is a top-level or not.
I wish people could keep these things straight. We’re not talking about
changing the semantics of how pattern matching works, which patterns match
what, what nesting means, etc. We’re
t; mailto:fo...@univ-mlv.fr>>
Cc: "amber-spec-experts"
mailto:amber-spec-experts@openjdk.java.net>>
Sent: Thursday, January 27, 2022 2:04:35 PM
Subject: Re: [External] : Re: Diamond in type patterns (was: Reviewing feedback
on patterns in switch)
It's more an engineering thi
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Thursday, January 27, 2022 2:04:35 PM
> Subject: Re: [External] : Re: Diamond in type patterns (was: Reviewing
> feedback
> on patterns in switch)
>> It's mo
It's more an engineering thing here, we have far more casts than switch +
pattern in existing code, and given that we suppose (perhaps wrongly) that the
semantics of the inference is not exactly one already existing,
I’d like to drill into this supposition. My supposition (maybe wrong) is that
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Wednesday, January 26, 2022 3:34:21 PM
> Subject: Re: [External] : Re: Diamond in type patterns (was: Reviewing
> feedback
> on patterns in switch)
>>
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "Tagir Valeev" , "amber-spec-experts"
>
> Sent: Wednesday, January 26, 2022 3:08:39 PM
> Subject: Re: [External] : Re: Treatment of total patterns (was: Reviewing
> feedback on patte
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Wednesday, January 26, 2022 3:30:45 PM
> Subject: Re: [External] : Re: Patterns and GADTs (was: Reviewing feedback on
> patterns in switch)
> I don’t object to hav
To summarize the feedback so far (please, don’t reply here, use the threads):
> 1. Treatment of total patterns in switch / instanceof
There seems to be overall inclination to adjust semantics of *switch* (not
patterns) to be more in line with historical switch behavior. This could be
ubject: Re: [External] : Re: Patterns and GADTs (was: Reviewing feedback on
patterns in switch)
The instanceof example is not a source backward compatible change, remember
that instanceof is not a preview feature.
I’m well aware, can you give an example where flow typing of *t
I think we should figure out how it should work on cast and then we can happily
applied it on patterns.
I’m happy to have the cast discussion happen concurrently, but right now, my
priority is on patterns, as we’re already two previews into patterns-in-switch.
But I’m not ready to say “we
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Wednesday, January 26, 2022 1:23:04 PM
> Subject: Re: [External] : Re: Diamond in type patterns (was: Reviewing
> feedback
> on patterns in switch)
>> Th
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "amber-spec-experts"
> Sent: Wednesday, January 26, 2022 1:28:19 PM
> Subject: Re: [External] : Re: Patterns and GADTs (was: Reviewing feedback on
> patterns in switch)
>> The instanceof exampl
mailto:amae...@gmail.com>>,
"amber-spec-experts"
mailto:amber-spec-experts@openjdk.java.net>>
Sent: Wednesday, January 26, 2022 1:47:38 PM
Subject: Re: [External] : Re: Treatment of total patterns (was: Reviewing
feedback on patterns in switch)
Heh, you are incrementally rediscov
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "Tagir Valeev" , "amber-spec-experts"
>
> Sent: Wednesday, January 26, 2022 1:47:38 PM
> Subject: Re: [External] : Re: Treatment of total patterns (was: Reviewing
> feedback on patterns i
Heh, you are incrementally rediscovering exactly why we chose the original
“total is total” rule; of all the possible treatments, it is the most logically
consistent. Welcome.
In this case, however, switches must be total. So here, either D is total
(perhaps with remainder), or B/C/D cover
> I strongly support this change.
>
> In my experience, it's much more important to have automatic
> refactorings between switch and chains of 'if' than between nested and
> flat switches.
Of course, this might be partially because we *have* chains of if else now, but
no switches on nested
> For the record: I like the current version with &&. It's short and
> easy to understand (as people already know what && means in Java). I
> see no reason in replacing it with `when`, which is more limiting.
I like the && syntax too (though we can invent some nasty puzzlers with
booleans, such
The instanceof example is not a source backward compatible change, remember
that instanceof is not a preview feature.
I’m well aware, can you give an example where flow typing of *type variables
only* might lead to incompatibility? (I’m aware that this is a possibility,
but you’re stating it
The questions we did not answer the last time we talk about that subject
- why should we allow raw types here ?
We already have a clear precedent with type patterns in instanceof — which is
not a preview feature any more. So for one, now you’re talking about making a
*change* to the existing
- Original Message -
> From: "Tagir Valeev"
> To: "Brian Goetz"
> Cc: "amber-spec-experts"
> Sent: Wednesday, January 26, 2022 4:50:05 AM
> Subject: Re: Positioning of guards (was: Reviewing feedback on patterns in
> switch)
> Hel
- Original Message -
> From: "Tagir Valeev"
> To: "Brian Goetz"
> Cc: "amber-spec-experts"
> Sent: Wednesday, January 26, 2022 5:20:24 AM
> Subject: Re: Treatment of total patterns (was: Reviewing feedback on patterns
> in switch)
>&g
> Null is only matched by a switch case that includes `case null`. Switches
> with no `case null` are treated as if they have a `case null: throw NPE`.
> This means that `case Object o` doesn’t match null; only `case null, Object
> o` does.
> Total patterns are re-allowed in instanceof
Hello!
For the record: I like the current version with &&. It's short and
easy to understand (as people already know what && means in Java). I
see no reason in replacing it with `when`, which is more limiting.
> because of the potential confusion should we ever choose to support switch
> over
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Tuesday, January 25, 2022 8:47:09 PM
> Subject: Treatment of total patterns (was: Reviewing feedback on patterns in
> switch)
>> 1. Treatment of total patterns in switch / instanceof
> The hand
- Original Message -
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Tuesday, January 25, 2022 8:49:02 PM
> Subject: Positioning of guards (was: Reviewing feedback on patterns in switch)
>> 2. Positioning of guards
>
> We rece
- Original Message -
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Tuesday, January 25, 2022 8:49:08 PM
> Subject: Patterns and GADTs (was: Reviewing feedback on patterns in switch)
>> 3. Type refinements for GADTs
>
> There ar
- Original Message -
> From: "Brian Goetz"
> To: "amber-spec-experts"
> Sent: Tuesday, January 25, 2022 8:49:12 PM
> Subject: Diamond in type patterns (was: Reviewing feedback on patterns in
> switch)
>> 4. Diamond for type patterns (and recor
> 4. Diamond for type patterns (and record patterns)
The type pattern `T t` declares `t`, if the pattern matches, with the type T.
If T is a generic type, then we do a consistency check to ensure soundness:
List list = …
switch (list) {
case ArrayList a: A // ok
> 3. Type refinements for GADTs
There are a number of unsatisfying aspects to how we currently handle GADTs;
specifically, we are missing the type refinement process outlined in "Simple
unification-based type inference for GADTs” (SPJ et al, 2005). Here are some
examples of where we fall
> 2. Positioning of guards
We received several forms of feedback over the form and placement of guarded
patterns. Recall that we define a guarded pattern to be `P && g`, where P is a
pattern and g is a boolean expression. Guarded patterns are never total. Note
that we had a choice of the
1. Treatment of total patterns in switch / instanceof
The handling of totality has been a long and painful discussion, trying to
balance between where we want this feature to land in the long term, and
people’s existing mental models of what switch and instanceof are supposed to
do. Because
We’ve previewed patterns in switch for two rounds, and have received some
feedback. Overall, things work quite well, but there were a few items which
received some nontrivial feedback, and I’m prepared to suggest some changes
based on them. I’ll summarize them here and create a new thread for
51 matches
Mail list logo
