[External] : Re: Primitive type patterns

[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: Monday, February 28, 2022 7:53:07 PM
> Subject: Re: [External] : Re: Primitive type patterns

>>> Now, what if instead of Object, we start with Long?

>>> Long l = 0L
>>> if (l instanceof byte b) { ... }

>>> First, applicability: does Long unbox to a primitive type that can be narrowed
>>> to byte? Yes! Long unboxes to long, and long can be narrowed to byte.

>>> Then: matching: if the RHS is not null, we unbox, and do a range check. (The
>>> rules in my previous mail probably didn't get this case perfectly right), but
>>> 0L will match, and 0xffff will not -- as we would expect.
>> This is totally alien to me, when you have x instanceof Foo (note: this is not
>> the pattern version) with X the type of x, then if x is declared with a super
>> type of X it works the exact same way, i.e i don't have to care to much about
>> the type on what i'm doing an instanceof / switching over it.

> Yes, I understand your discomfort. And I will admit, I don't love this
> particular corner-of-a-corner either. (But let's be clear: it is a corner. If
> you're seeking to throw out the whole scheme on the basis that corners exist,
> you'll find the judge to be unsympathetic.)

> So why have I proposed it this way? Because, unfortunately, of this existing
> line in JLS 5.2 (which I never liked):

> > an unboxing conversion followed by a widening primitive conversion

> This is what lets you say:

> long l = anInteger

> And, I never liked this rule, but we're stuck with it. The inverse, from which
> we would derive this rule, is that

> anInteger instanceof long l

> should be applicable, and in fact always match when the LHS is non-null. I would
> prefer to not allow this assignment conversion, and similarly not allow both
> unboxing and widening in one go in pattern matching, but I didn't get to write
> JLS 5.2.

> What's new here is going in the *other* direction:

> anInteger instanceof short s

> and I think what is making you uncomfortable is that you are processing two
> generalizations at once, and it's pushing your "OMG different! scary!" buttons:

> - that we're defining primitive type patterns in a way such that we can derive
> the existing assignment conversions;
> - that primitive type patterns can have dynamic checks that primitive
> assignments cannot, so we're including the value-range check.

> Each individually is not quite as scary, but I can understand why the two
> together would seem scary. (And, as I mentioned, I don't like the
> unbox-and-widen conversions either, but I didn't invent those.)

I think we should play on our strengths, destructuring instead of unboxing, pattern methods instead of primitive conversions + rangecheck. 
I prefer to have a few small well defined patterns (type pattern, type destructuring, pattern method) each with a simple semantics (so keep the type pattern to be about subtyping relationship only) and draw power from the ability to compose them instead of having patterns with a huge semantic baggage (type pattern with the assignment semantics) and the corner cases that come with it. 

We may still need assignment conversions when we mix pattern and assignment, but because we want to be "backward compatibility" with the simple assignment semantics. 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220228/ea28c4f8/attachment.htm>