The rules for scoping outlined here
http://cr.openjdk.java.net/~briangoetz/amber/pattern-semantics.html
<http://cr.openjdk.java.net/~briangoetz/amber/pattern-semantics.html>
certainly covered the propagation of binding variables through ternaries. And
those rules appear to be covered by 6.3.1.4 in Gavin’s draft.
We value being able to freely refactor between the ternary expression and
if-statement forms; if you’ve got examples where that can’t be done, or where
the semantics and scoping differ, please point those out!
> On Sep 20, 2019, at 9:57 AM, Remi Forax <fo...@univ-mlv.fr> wrote:
>
> 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.bier...@oracle.com>
> À: "amber-spec-experts" <amber-spec-experts@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
>
