Obviously this is still an early proposal that might not go anywhere, but I find it interesting to see how more and more functional programming constructs are creeping into Java. Who knows if this makes it in, next they make exceptions resumable and they go all the way to typed effects.
This doesn't necessarily seem like functional programming (although there's nothing wrong with functional programming). It makes sense to unify switch and try-catch statements, because they're both meant for selecting a path based on the outcome of the selector expression (as the proposal says). It would make sense for other languages with exceptions, like C++, to adopt something like this, IMO.
> Who knows if this makes it in, next they make exceptions resumable and they go all the way to typed effects.
You don't necessarily need that for resumable exceptions. Common Lisp and PL/I got it a long time ago, although PL/I isn't really in use anymore AFAIK.
Apparently, resumable exceptions used to be more commonly accepted, and then they were rejected in the 1980s[1]:
> Originally, software exception handling included both resumable exceptions (resumption semantics), like most hardware exceptions, and non-resumable exceptions (termination semantics). However, resumption semantics were considered ineffective in practice in the 1970s and 1980s (see C++ standardization discussion, quoted below) and are no longer in common use, though provided by programming languages like Common Lisp, Dylan and PL/I.
I wasn't around then, which is why I say "apparently."
Python has been getting a bunch of similar features too. ADTs+Pattern Matching form an incredibly powerful pair of features that leads to code that is both concise and easy to read, so it doesn't surprise me that it's getting retrofitted into all sorts of languages.
Java is not becoming Scala and that is good. I am saying that as someone earning his bread with mostly writing Scala and SQL nowadays. Scala's underlying type theory is quite different from Java and that lead to many of its pitfalls.
I really admire Brian Goetz's slow and steady hand to extend Java piece by piece with those language constructs, that are understood well enough. Scala started as an experiment to unify a functional language with an object-oriented language. Thereby, they created this monstrosity of a type systems which fails to give the guarantees of Haskell 98 types, but provides all the bells and whistles of Haskell 2010 + GADT + UndecidableInstances. And at the same time the type systems is shoehorned into the type system of the JVM. All that is quite an engineering achievement. And it was/is an extremely valuable research experiment. But it is far from simple.
I hope Java continues to walk the path well trodden. Then it can continue to be the boring technology, the safe choice, the reliable tool it is. Although it is evolving faster than ever.
My dream of getting to write more-OCaml-esque code at my day job continues to flourish. I'm glad bright minds in language design for the "majority" languages are looking to the wisdom found in more-niche languages.
Unless, of course, you find yourself in one of the languages with broken associativity or precedence.
`? :` has to be right-associative, and should have the lowest precedence of any "normal" expression (only assignment and comma expressions are lower). Note however that the middle expression does not care about associativity, though readability suffers if it has a lower precedence than the ternary itself (a ? b = c : d).
As far as prettified indentation goes:
* if any argument is itself a ternary, force a break before it
* if you have to break after `?`, indent
* if you have to break after `:`, indent unless the following is a ternary
**
Note also that logical if-then-else is not actually the only kind of ternary expression; it's just the only one that C exposes. Common other ternary expressions in some contexts include: bitwise if-then-else (aka select - note that the famous bithacks page lies about xor being cheaper, since it forgets that andnot is a primitive), modular exponentiation, fused multiply-add, bitsearch (unless your type system can supply the needle width), various "foo and right shift" that would otherwise return more than a register (foo = multiply, interleave, lcm, pow) and "foo and left shift" that would return a fraction (foo = div, sqrt, cbrt). Passing in a rounding mode or something can also add an argument to many ops.
How's this for something pulled from the archives... when I was studying OCaml I saved a link to the presentation where the feature was introduced into that language :) https://youtu.be/DMzZy1bqj6Q?t=45
I do in general like all the nice improvements they've been making to Java over time (as someone who loved Scala back in 2015 or so). But this is silly; they should introduce a sealed `Try` type like Scala has (or, well, just steal the version from the Java "vavr" library), with `Success`/`Failure` record implementations, and then you can destructure in the switch statement. So something like https://java.godbolt.org/z/dh5ebPfeq
The benefit there is that it doesn't require any changes to language or syntax. Hell, you can even use vavr's `Try` and achieve the same effect, though I guess you can't destructure in the same way as it doesn't use record.
I imagine that many suggestions for prominent open source projects, let alone a widely adopted language, turn into forums similar to small town town-hall meetings.
There are probably a number of people of different walks of life and usage of the lang that voice opinions regardless of their relevance or significance in modern adoption of the lang.
There’s already been strong reactions by some in the Java subreddit. A lot have bike shedding over syntax and some just don’t like the idea of handling exceptions this way.
