Draft JLS spec for JEP 305: Pattern matching for instanceof

[Remi Forax]

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>