groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
Date Fri, 09 Mar 2018 22:23:34 GMT
On 08.03.2018 20:52, Remi Forax wrote:
> using break here is ugly, i agree with you but we (the amber EG) are not able to find
a better solution,
> if you know a better way to handle local return of a value in the case of a switch, please
help us.

should inspiration strike me I will let you guys know ;)

> no, the Java part of the pattern matching is mostly decided (there is still corner cases
like how re-starting when a guard fails).
> The pattern matching is delayed more because
> 1/ the VM support is not there, part will be in the jdk 11, but how to specify a sealed
interface to avoid to have to specify a default when you have cover all the cases is still
> 2/ the support of de-constructor (extractor) to keep encapsulation without allocation
in the middle of the pattern matching requires:
>     2a/ value types, good progress have been made on the valhalla side, a release of
value types without changing generics (which is a major PITA) may be a temporary solution.
>     2b/ another temporary solution is to make pattern matching only working on records
(data classes).
> The only part of the pattern matching which is ugly IMO is how to specify a "local return"
of a value in a case with several instructions.

I really do not want to sound like a broken record, but I really think 
the local return problem is no problem with the lambda version. Its 
limitations are already accepted there. Of course it is unfair to jump 
in with a comment like that, without taking the time to see what was 
worked out and why before.

As for the deconstructor... yes I was really curious about how that 
problem is going to be solved.

> Now, releasing an expression switch first has several advantages:
> - allow to align the old switch with the pattern matching switch by modernizing the behavior
of the old switch with respect to null.


> - it fixes several bugs of the current switch implementation:
>    - having to recompile the switch when you change the enum
>    - the switch on string being slow when the number of cases is small
>    - reduce the switch footprint in term of bytecodes

sounds good, but I have to see how useful this is outside the intended 
use for pattern matching. It is for example unlikely to replace our most 
annoying switch-case usage in Groovy internally, which is to select the 
right "super" and "this" delegation call in a constructor

> - and obviously allow to use a switch that "returns" an expression.

I don't think I would like to think of it as returning an expression ;)

In total I am not fully convinced that a lambda usage is bad here. But 
then again maybe I am more willing to live with some trade-offs coming 
from that approach than the EG is. It is just...
* reusing syntax elements and give it new semantics is bad
* introducing new syntax elements should be avoided

Those are principles I go with in language design. Sure,you can not 
always keep that,so it is to be weighted with the gain, but the 
switch-expressions seem to have quite the initial momentum to overcome 
to show its value like that.

bye Jochen

View raw message