Hi Gavin, all,
For the issue “Switch coverage with multiple branches” raised in
https://mail.openjdk.java.net/pipermail/amber-spec-experts/2021-July/003049.html
by Dan [yeah – I know it’s a little late to ask this, but still :( ], I
couldn’t figure out a spec change in JEP 420 - from the relev
As we move towards the next deliverable -- record patterns -- we have
two new questions regarding exceptions to answer.
Questions
1. When a dtor throws an exception. (You might think we can kick this
down the road, since records automatically acquire a synthetic dtor, and
users can't w
> 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 NotStringException();
> 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 developers, one routinely
> expects
> to get complaints a
> 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 question about let/bind, under the
> condition that we not di
> 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 question is more a question of consistency. There are two consistenc
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 ne
> 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-legacy switches (legacy type, legacy labels, stat
> 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 than "when" because i've written more switch that
>>> uses && than "when".
>>
Of course, in an ecosystem as diverse as Java developers, one routinely
expects to get complaints about both X and ~X. Which makes it notable
that we have not gotten any complaints about "why do you force me to
write an empty default". (I'm not complaining!)
The case you raise -- legacy { sw
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 it.
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 or
14 matches
Mail list logo
