> From: "Brian Goetz" <brian.go...@oracle.com> > To: "amber-spec-experts" <amber-spec-experts@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 ? Rémi
