Draft JLS spec for JEP 305: Pattern matching for instanceof
forax at univ-mlv.fr
forax at univ-mlv.fr
Fri Sep 20 14:10:43 UTC 2019
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Gavin Bierman" <gavin.bierman at oracle.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Envoyé: Vendredi 20 Septembre 2019 16:01:14
> Objet: Re: Draft JLS spec for JEP 305: Pattern matching for instanceof
> 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.
my bad, for whatever reason, i've not seen that section.
> 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!
Rémi
>> On Sep 20, 2019, at 9:57 AM, Remi Forax < [ mailto:forax at univ-mlv.fr |
>> forax at 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" < [ mailto:gavin.bierman at oracle.com |
>>> gavin.bierman at oracle.com ] >
>>> À: "amber-spec-experts" < [ mailto:amber-spec-experts at openjdk.java.net |
>>> 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/b68b6c35/attachment.html>
More information about the amber-spec-experts
mailing list