On 3/4/2022 5:37 AM, fo...@univ-mlv.fr wrote:
------------------------------------------------------------------------
*From: *"Brian Goetz" <brian.go...@oracle.com>
*To: *"Remi Forax" <fo...@univ-mlv.fr>
*Cc: *"amber-spec-experts" <amber-spec-experts@openjdk.java.net>
*Sent: *Friday, March 4, 2022 3:23:58 AM
*Subject: *Re: [External] : Re: Telling the totality story
#### Let
This is where it gets ugly. Let has no opinions about
null, but the game here is to pretend it does. So in a
let statement:
let P = e
- Evaluate e
- If e is null
- If P is a covering pattern, its binding is bound to null;
- else we throws NPE
- Otherwise, e is matched to P. If it does not match
(its remainder), a MatchException is thrown (or the else
clause is taken, if one is present.)
It's not clear to me why a MatchException should be thrown
instead of not compiling if not exhaustive.
You're confusing "exhaustive" and "total". A let must be
exhaustive, but exhaustiveness != totality.
It's mean that there are remainders that does not lead to
either a NPE or an error, do you have an example of such
remainder ?
Yes. Suppose we have records Box<T>(T t) and Pair<T, U>(T t, U
u), and A is sealed to B|C. Then if we're matching on a
Pair<Box<A>, A>, then
Pair(null, B)
Pair(Box(B), D) // D is a type from the future
Pair(Box(D), B)
Pair(Box(D), D)
Pair(null, D)
are all in the remainder. It is a big stretch to claim either NPE
or ICCE is right for any of these, and completely arbitrary to
pick one for Pair(null, D). Also, its much more expensive to try
to distinguish between these, and pick the "right" error for each,
rather than insert a default clause that throws
MatchRemainderException.
The exception are here because the view at runtime and the view at
compile time are slightly different
- an NPE is raised when a value is null but the pattern ask for a
deconstruction
- an ICCE if the compiler has use a sealed type during it's analysis
and the sealed type has changed
This was a thread about pedagogy. You asked a factual question (though
tangential) for clarification, which is fine, and got an answer. But
then you used the answer to spin off into a "let me redesign a feature
that is unrelated to the thread." That's not so good.
There actually was a thread about exceptions, where we could have
discussed this (and we did, I think; these points here mostly seem
repeated.) By diverting this thread, it means we may not get back to
the main point -- something I put time into because I wanted feedback.
So far, we're three replies-to-replies into the weeds, and no one has
talked about pedagogy. And likely, no one will, because once a thread
has been diverted, it rarely comes back.
