[External] : Re: Treatment of total patterns (was: 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: "Tagir Valeev" <amaembo at gmail.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Sent: Wednesday, January 26, 2022 3:08:39 PM
> Subject: Re: [External] : Re: Treatment of total patterns (was: Reviewing
> feedback on patterns in switch)

> I don’t think its helpful to try and reopen these old and settled issues. I get
> that you think null should have a larger syntactic presence in the language,
> and you’ve made those points plenty of times, but we’re not reopening whether
> `Object o` is total, or whether `var` is more than type inference. We’re
> focused here on the interaction between switch and patterns, precisely because
> switch comes to the table with pre-existing null hostilities. We are not going
> to distort the semantics of pattern matching just so we can extrapolate from
> how C switch worked; we’ve been over this too many times.
In that case, i prefer the current semantics because it's the same if a pattern is a top-level or not. 

Rémi 

>> On Jan 26, 2022, at 8:45 AM, [ mailto:forax at univ-mlv.fr |
>> forax at univ-mlv.fr ] wrote:

>>> From: "Brian Goetz" < [ mailto:brian.goetz at oracle.com | brian.goetz at oracle.com ]
>>> >
>>> To: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >
>>> Cc: "Tagir Valeev" < [ mailto:amaembo at gmail.com | amaembo at gmail.com ] >,
>>> "amber-spec-experts" < [ mailto:amber-spec-experts at openjdk.java.net |
>>> amber-spec-experts at 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 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 whatever the content of Box is, or it
>>> doesn’’t compile. If there is remainder (which is likely to be null, but which
>>> won’t happen with a type pattern, only when D is more complicated), and no
>>> later case handles Box(null), then the switch will NPE. We don’t know if
>>> Box(null) is matched by any of these cases, but we *do* know that we will not
>>> arrive at the statement after the switch if the target was Box(null).

>> It's true that if you can observe the different side effects when the code is
>> run, and from that you may have an idea if case Box(D d) matches or not (and
>> prey that there is not a catch() in the middle),
>> but the bar is very low if you say that to understand a code you have to run it.

>>> The proposed change to top-level null hostility doesn’t affect that.

>> yes, that my point, having to run a code to understand it is a clue that the
>> semantics you propose or the Java 18 one are both equally bad.

>> Again, the C# semantics does not have such problem, if we suppose that the code
>> compiles then with the code below, d can not be null

>> switch(box) {
>> case Box(B b) -> { }
>> case Box(C c) -> { }
>> case Box(D d) -> { } // does not accept null
>> }

>> while with this code, d can be null

>> switch(box) {
>> case Box(B b) -> { }
>> case Box(C c) -> { }
>> case Box(var d) -> { } // accept null
>> }

>> Rémi

>>>> On Jan 26, 2022, at 2:53 AM, Remi Forax < [ mailto:forax at univ-mlv.fr |
>>>> forax at univ-mlv.fr ] > wrote:

>>>> We should go a step further, this also means that with

>>>> switch(box) {
>>>> case Box(B b) -> {}
>>>> case Box(C c) -> {}
>>>> case Box(D d) -> {}
>>>> }

>>>> we have no idea if the switch will accept Box(null) or not.

>>>> So the idea that a type behave differently if nested inside a pattern or not is
>>>> not a good one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220127/091c32cd/attachment-0001.htm>