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

[forax at univ-mlv.fr]

> From: "jan lahoda" <jan.lahoda at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Jan Lahoda" <jlahoda at openjdk.org>, "Brian Goetz" <brian.goetz at oracle.com>,
> "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Sunday, August 7, 2022 11:22:28 AM
> Subject: Re: [External] : Re: RFR: 8291769: Translation of switch with record
> patterns could be improved

> On 07. 08. 22 10:19, [ mailto:forax at univ-mlv.fr | 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
>>> |
>>> 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.)
I'm ok with this PR but in the long term i hope we can make a better job. 
I still fear people re-organizing their patterns to get more performance instead of getting good performance out of the box. 

> Jan
Rémi 

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