[External] : Re: RFR: 8291769: Translation of switch with record patterns could be improved

Jan Lahoda jan.lahoda at oracle.com
Sun Aug 7 09:22:28 UTC 2022


On 07. 08. 22 10:19, forax at univ-mlv.fr wrote:

> [...]
>
>         "provide new bindings" => do you have an example of that ?
>
>
>     Sure:
>
>     public class TA {
>        public static void main(String... args) {
>            Object o = new Box("");
>            switch (o) {
>                case Box b when b.o() instanceof String s ->
>     System.err.println(s);
>                default -> {}
>            }
>        }
>        record Box(Object o) {}
>     }
>
>
>     (There can be any number of new bindings from the guard, of course.)
>
>
>         I don't think a guard should be allowed to do that. It looks like a big gunfoot to me.
>
>
>     I believe the current specification supports guards that introduce
>     new bindings:
>
>     http://cr.openjdk.java.net/~gbierman/jep427%2b405/jep427+405-20220601/specs/patterns-switch-record-patterns-jls.html#jls-6.3.4
>
>
>     To me, it seems desirable. In any case, an implementation PR is
>     probably not very well suited to discuss opinions on what should
>     be specced. In particular (but not only) a PR that is not expected
>     to change the semantics.
>
>
> Ok, thanks for the example, it means we should lift the when 
> expression not has a static method but as a static pattern method, 
> something which will be more clear when we will have a better idea 
> about how to do that once user defined pattern method like 
> Optional.of(value -> ...) will be introduced.


Which I guess leaves as with a question: what are we going to do until 
user patterns are defined. Do we keep the current slow code, or do we 
try to improve that (which is that this PR is trying to do)? (And maybe 
learn something in the process.)


Jan


>
> Rémi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20220807/7326a6cc/attachment.htm>


More information about the compiler-dev mailing list