Draft JLS spec for JEP 305: Pattern matching for instanceof

[Remi Forax]

I don't remember if we have discuss this or not but if i read the spec correctly, 
there is no support for the operator ?: 

so a code like this is ok 
if (o instanceof String s) { 
return s.length(); 
} else { 
return 0; 
} 

while a code like this is not 
return (o instanceof String s)? s.length(): 0; 

supporting the "if statement" without supporting the "if expression" seems arbitrary given the duality of both constructs. 

Rémi 

> 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

> 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)?

>> if (o instanceof List<Integer> l) {
>> …
>> }

> 2. We’d like to keep the possibility open for merging of multiple pattern
> declarations, where it makes sense. For example:

>> if (a instanceof Foo f || b instanceof Foo f) {
>> … // Like to be able to use f here
>> }

> 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…)

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190920/4b7901e0/attachment.html>