switch statement and lambda
forax at univ-mlv.fr
forax at univ-mlv.fr
Tue Apr 9 19:39:58 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é: Mardi 9 Avril 2019 21:14:25
> Objet: Re: switch statement and lambda
> I see why this is tempting, but I am going to suggest we wait. As part of
> Valhalla, we would like for `void` to become a real type some day; that will
> require evaluating all the places in the JLS where we treat statement and
> expressions differently, or make exceptions like this. Until we’ve completed
> this analysis, I’m reluctant to add more special cases.
seems wise, ok !
Rémi
>> On Apr 9, 2019, at 3:10 PM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ]
>> wrote:
>>> De: "Gavin Bierman" < [ mailto:gavin.bierman at oracle.com |
>>> gavin.bierman at oracle.com ] >
>>> À: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >
>>> Cc: "amber-spec-experts" < [ mailto:amber-spec-experts at openjdk.java.net |
>>> amber-spec-experts at openjdk.java.net ] >
>>> Envoyé: Mardi 9 Avril 2019 19:28:57
>>> Objet: Re: switch statement and lambda
>>>> On 6 Apr 2019, at 21:17, Remi Forax < [ mailto:forax at univ-mlv.fr |
>>>> forax at univ-mlv.fr ] > wrote:
>>>> Currently this code doesn't compile
>>>> IntConsumer c = x -> switch(x) { default -> System.out.println(x); };
>>>> I believe it should because this is the basic pattern for supporting the actor
>>>> model,
>>>> you consume a message and do a side effect* depending on the type of the
>>>> message,
>>>> translated in Java, you want a lambda that takes a message as parameter, calls a
>>>> switch to do the pattern matching and return void.
>>> I understand, although this is actually to do with the way lambda expressions
>>> are typed, rather than the switch expression. In JLS 15.27.3 "Type of a Lambda
>>> Expression”, there is a special case:
>>> • If the function type's result is void, the lambda body is either a statement
>>> expression (§14.8) or a void-compatible block.
>>> Which means that the following code typechecks:
>>> IntConsumer ic = x -> System.out.println(x);
>>> but it breaks as soon as we nest the statement expression, e.g.
>>> IntConsumer ic2 = x -> true ? System.out.println(x) : System.out.println(x); //
>>> Compilation error: target-type for conditional expression cannot be void
>>> This is what is happening in your example. So to deal with this we’d either have
>>> to make typechecking of lambdas smarter - either by replacing the typing rule
>>> for lambdas above with something more compositional, or by making void a
>>> first-class type, or we could perhaps add a pattern-matching form of lambda,
>>> which has a void-aware typing rule. I’m not sure about any of these options for
>>> now.
>> yes,
>> i'm proposing to create a special case for a switch inside a lambda expression
>> for the same reason we have a special treatment for methods.
>> By example, this does not compile
>> [ https://github.com/fora | https://github.com/fora ]
>> x/loom-fiber/blob/cea7b86c26c2e86b00fb72e5098a37983e8b6441/src/main/java/fr.umlv.loom/fr/umlv/loom/actor/CounterStringActorExprSwitchDemo.java#L17
>> while this compiles
>> [
>> https://github.com/forax/loom-fiber/blob/6d8a0a6ba870580d43988cd0d507d19d57653d62/src/main/java/fr.umlv.loom/fr/umlv/loom/actor/CounterStringActorExprSwitchDemo.java#L17
>> |
>> https://github.com/forax/loom-fiber/blob/6d8a0a6ba870580d43988cd0d507d19d57653d62/src/main/java/fr.umlv.loom/fr/umlv/loom/actor/CounterStringActorExprSwitchDemo.java#L17
>> ]
>>> Cheers,
>>> Gavin
>> cheers,
>> Rémi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190409/198a8e25/attachment.html>
More information about the amber-spec-experts
mailing list