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 open.
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.
+1
- 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
