Re: Patterns design question: Primitive type tests

> De: "Brian Goetz" > À: "Remi Forax" > Cc: "Gavin Bierman" , "amber-spec-experts" > > Envoyé: Vendredi 3 Novembre 2017 21:53:50 > Objet: Re: Patterns design question: Primitive type tests > Note that is really just about primitives, as they are the only ones whose > value > sets have non-triv

Re: default branch placement in switch

Yeah, this has to change.  In existing switches, there are no case labels other than default, so order is irrelevant.  But now that patterns have overlapping match-sets, default should be considered to dominate other cases, so it should go last. Compatibility-wise, we have two choices for how

default branch placement in switch

Hello! Currently the default branch can be placed in any place inside the switch operator, e.g. like this: switch(i) { case 1: System.out.println("one");break; default: System.out.println("other");break; case 2: System.out.println("two");break; } In this case behavior does not change on the orde

Re: Patterns design question: Primitive type tests

Note that is really just about primitives, as they are the only ones whose value sets have non-trivial intersection.  Value types, being non-polymorphic and having no nontrivial overlap, won't have this problem. Arguably, for strongly typed literals ("case 0.0f"), we could allow them against a

Re: Patterns design question: Primitive type tests

I'm happy with choice #3 too. #2 is a sad choice because this semantics is not explicit, #2 means instanceof + unboxing + widening but nowhere in the syntax the wrapper type used for the instanceof and the unboxing appears. Not having the wrapper type mentioned doesn't pass my semantics smell

Re: Patterns design question: Primitive type tests

As I outlined in the mail on the survey, I think there are three possible ways to treat primitive type test patterns and numeric constant patterns (when the target type is a reference type): 1.  Treat them as if they were synonyms for their box type. 2.  Treat them as matching a set of values;

Survey on primitive type test patterns

You may have seen a survey float by a few days ago, aimed at probing at developer intuition about the semantics of primitive type test patterns. The results are here, with over 1000 answers: https://www.surveymonkey.com/results/SM-87Y6K3BY8/ BACKGROUND The real goal of this survey was t

Re: Data classes

- Mail original - > De: "Brian Goetz" > À: fo...@univ-mlv.fr > Cc: "amber-spec-experts" > Envoyé: Jeudi 2 Novembre 2017 16:05:33 > Objet: Re: Data classes >> In the proposal, you discuss about adding keywords like "non-final, unfinal, >> mutable", i.e. considering that there can be a d

Patterns design question: Primitive type tests

Primitive type-test patterns Given that patterns include constant expressions, and type tests possibly including generic types; it seems reasonable to consider the possibility of allowing primitive type tests in pattern matching. (This answers a sometimes-requested feature: can instanceof suppo

Patterns design question: Nulls

Nulls and pattern matching The null value is treated somewhat inconsistently in Java; unfortunately pattern matching places a fresh focus on these inconsistences. Consider a local variable, String s=null;. Currently s instanceof String returns false; whereas (String)ssucceeds; and further switc

Patterns design question: Generics

Generics A related problem to the issue of null and pattern matching is dealing with patterns mentioning generic types. Currently, it is forbidden to use instanceof with a non-reifiable type. However, we suspect that Java programmers would expect the following to work: ArrayList al = ... if (a

PM design question: Scopes

Scopes Java has five constructs that introduce fresh variables into scope: the local variable declaration statement, the for statement, the try-with-resources statement, the catch block, and lambda expressions. The first, local variable declaration statements, introduce variables that are in sc

PM design question: Shadowing

Shadowing As mentioned in the previous email, Java currently has five constructs that declare fresh variables. All five declare variables under the same shadowing regime: (i) No shadowing of formal parameters, (ii) No shadowing of other locally declared variables, but (iii) shadowing permitted

Questions on pattern matching

Dear Spec Experts, In our development of the pattern matching feature a number of fairly fundamental design questions have arisen. In the following series of emails, I will try to explain the question and describe some of the solutions that have come to mind. Please do let us know of any though