Evolving past reference type patterns

Remi Forax forax at univ-mlv.fr
Fri Apr 15 22:13:29 UTC 2022

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Sent: Friday, April 15, 2022 10:50:27 PM
> Subject: Evolving past reference type patterns


> There are also some small differences between the safe cast conversions and
> method invocation context. There is the same issue with unboxing null (throws
> in (loose) invocation context), and method invocation context makes no attempt
> to do narrowing, even for literals. This last seems mostly a historical wart,
> which now can’t be changed because it would either potentially change (very
> few) overload selection choices, or would require another stage of selection.

It's not an historical wart, it's careful design (or co-design between the language and the VM). 
Assignments can be used for fields, that are stored on heap, while method arguments can only be stored on stack. 
Values on stack/in registers are either 32 bits or 64 bits while values on the heap are multiple of 8 bits. 

That's the same reason why the result of the addition of two shorts is an int and why assignment conversions in the context of a computation (the pattern matching helps to express computation) feels weird. 

> What are the arguments against this interpretation? They seem to be various
> flavors of “ok, but, do we really need this?” and “yikes, new complexity.”

> The first argument comes from a desire to treat pattern matching as a
> “Coin”-like feature, strictly limiting its scope. (As an example of a similar
> kind of pushback, in the early days, it was asked “but does pattern matching
> have to be an expression, couldn’t we just have an “ifmatch” statement? (See
> answer here: [
> http://mail.openjdk.java.net/pipermail/amber-dev/2018-December/003842.html |
> http://mail.openjdk.java.net/pipermail/amber-dev/2018-December/003842.html ] )
> This is the sort of question we get a lot — there’s a natural tendency to try
> to “scope down” features that seem unfamiliar. But I think it’s
> counterproductive here.

We all know that this is a big feature, don't worry. 

> The second argument is largely a red herring, in that this is not new
> complexity, since these are exactly the rules for successful casts. In fact,
> not doing it might well be perceived as new complexity, since it results in
> more corner cases where refactorings that seem like they should work, do not,
> because of conversions.
It is new complexity, the rules for primitive narrowing are brand new. 

Can you provides examples of such refactorings ? 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220416/f40843c0/attachment-0001.htm>

More information about the amber-spec-experts mailing list