How much of what he explains in the video is doable today?
He basically wants to encode pattern matching using a lambda factory technique to avoid all allocations as well as boxing, in a generic way that allows even for returning tuples without overhead (I know that we today have the nominal pattern matching but that’s still one allocation, though escape analysis quite possible takes care of it). Today scala deals with the possible overhead by doing lots of optimizations after the fact (like tuple elimination), but how much would that help scala and how much of that is doable today would be my question.
I attended JVMLS and chatted to Brian and a few of the other Java team about this.
Firstly, they hope to deliver as much of the feature as possible in the runtime so that it can be shared with other Languages. LambdaMetafactory is a good precedent for this.
There are two areas of efficiency where they hope to improve over the status quo:
For extractor patterns, avoid boxing into a Some and Tuple. Scala has experimented with name based pattern matching as a solution here, but it is fairly hard to use IMO. As you noted, we don’t have this overhead today for case class patterns, which are the most commonly used.
Translation of the pattern themselves is deferred until link time, allowing for some more optimization possibilities.
It should be able to subsume the existing compiler support in Javac for switch on string/enum, which is also something we’d like to use.
I’m going to take a deeper look at the design and prototype and evaluate the impedence mismatches with scalac.