Submitting a JEP

[Daniel Trebbien]

On Fri, Oct 6, 2017 at 10:14 AM, Mario Torre <neugens.limasoftware at gmail.com
> wrote:

> I'm reading the proposal a bit and I don't think it's a very good idea
> to introduce another keyword.
>
> While it may be nice to have such statement, effectively you are
> promoting bad programming use cases.
>
> If we take the stack overflow link as an example, it's clear that the
> developer could simply rearrange his code to be more stable by using
> some of the advanced features of Java like classes and inheritance ;)
> or at worse by just documenting the need to add the return after the
> else branch
>

This wasn't explicitly stated in my proposal, but I am the one who asked
the question on Stack Overflow.

In my case, the code in question (part of my SLF4J Helper plugin for
NetBeans IDE; http://plugins.netbeans.org/plugin/72557/slf4j-helper )
performs static analysis of Java code through its representation as Java
compiler tree object hierarchies and javax.lang.model types.  It is not
particularly easy programming because I have to try to understand and
handle without exception every possible object hierarchy representing an
expression tree that the plugin might see in attempting to analyze some
piece of Java code.  This is complicated by things like ErroneousTree (
https://docs.oracle.com/javase/8/docs/jdk/api/javac/tree/com/sun/source/tree/ErroneousTree.html
) and ErrorType (
https://docs.oracle.com/javase/8/docs/api/javax/lang/model/type/ErrorType.html
) whose existence implies to me that the object hierarchies that my plugin
could encounter might not even correspond to well-formed code.

If all branches of the if-else if-else chain ended with a return statement,
then you're right that I could factor out that code into a helper method
and return the result of calling that helper method in the switch case.
But, not all branches return something.  Some branches continue or break an
enclosing loop, for example.

I do have comments explaining the need to prevent fall-through.  This is
not a very nice solution, however, because like Mr. Lloyd's DFA parsing
example, the code does not fit on one screen.  So, I could duplicate the
comments at the top and bottom, but still not see them depending on where I
am in the code.


>
> In all the other examples you give in the proposal, unless I'm
> misreading them, it seem that they are not unreachable statements in a
> sense that can the statically defined, but are simply cases that the
> developer "knows" they won't happen, but they may, and so they can be
> solved by an assert or by a runtime exception.
>
> So the only use case I see is the stack overflow one, but it seems to
> me this is just bad code practices, which is branching points with
> multiple return statements, that is always asking for troubles.
>
> In the short term future we will get enhanced switches with patterns,
> which turns switches into expression, and it makes the stack overflow
> example a lot easier to write without side effects.


This seems like Rust's pattern matching.  Practically everything in Rust
can be used as an expression, including `match', which is similar to the
`switch' statement in Java.  For example, here is some Rust code that I
wrote to parse Valgrind suppression files:
https://github.com/dtrebbien/valgrind-rs/blob/4b26c6f/src/lib.rs#L196  This
updates the parsing state based on the result of `match' on the current
parsing state.

While nifty, I don't think "expression switches" would address the problem.