Draft JLS spec for JEP 305: Pattern matching for instanceof
Remi Forax
forax at univ-mlv.fr
Fri Sep 20 14:03:37 UTC 2019
De: "Gavin Bierman" <gavin.bierman at oracle.com>
À: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
Envoyé: Jeudi 19 Septembre 2019 11:28:42
Objet: Draft JLS spec for JEP 305: Pattern matching for instanceof
BQ_BEGIN
A draft language spec for JEP 305 (Pattern Matching for instanceof) is available at:
[ http://cr.openjdk.java.net/~gbierman/jep305/jep305-20190918/specs/patterns-instanceof-jls.html | http://cr.openjdk.java.net/~gbierman/jep305/jep305-20190918/specs/patterns-instanceof-jls.html ]
Comments are welcomed on all aspects, but I draw your attention to a couple of things that we’d like your feedback on:
1. The instanceof operator restricts the type to be a reifiable reference type. The spec currently keeps that restriction for type test patterns too. But should we go further, i.e. will people expect to be able to say the following (given that this *declares* a pattern variable l)?
BQ_BEGIN
if (o instanceof List<Integer> l) {
…
}
BQ_END
BQ_END
If we allow such case, the compiler will have to emit an unchecked warning because this code is not safe.
So in a sense, you are asking if we want to support a construct we know is unsafe,
I think i prefer to see code with an explicitly cast instead
if (o instanceof List<?> l) {
var l2 = (List<Integer>) l;
}
Obviously, we may revisit that either if people ask for it or when semi-reified generics will be introduce by Valhalla.
BQ_BEGIN
2. We’d like to keep the possibility open for merging of multiple pattern declarations, where it makes sense. For example:
BQ_BEGIN
if (a instanceof Foo f || b instanceof Foo f) {
… // Like to be able to use f here
}
BQ_END
The current spec explicitly calls out cases like these as compile-time errors, to allow for forwards compatibility if we add this feature. But what do you think of this feature? (We have textually multiple declarations of a pattern variable, but they are “merged”, so they are really the same thing…)
BQ_END
I'm not a fan of merging variable declarations, it's too clever and force people to read the code too carefully to be a good feature.
BQ_BEGIN
3. [Only for spec nerds] I am proposing to add a new Chapter 16 to discuss patterns (at the moment it’s short, but we’re planning for it to grow). The existing Chapters 16-19 will be renumbered to 17-20. Will this renumbering cause problems for anyone?
Thanks,
Gavin
BQ_END
Rémi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190920/ac81c292/attachment-0001.html>
More information about the amber-spec-experts
mailing list