JEP 325: Switch Expressions

Clojure macros have spoiled me with cond, condp and case plus whatever else I or the community come up with. And my half thought out changes are nicely isolated to a single project or library instead of baked into the language for eternity.

Within a function, each switch branch can be a return. Then you get the benefits:

* Make the original function shorter.

* Give a descriptive name to what you're computing.

* Make the computation reusable.

It's what I find lacking with lambdas: it makes it too easy to forego good refactoring because it makes too easy to write one-off code that in reality will be rewritten many times in different places.

The footgun of 'break' in switch statements has always bothered me, I strongly prefer the kotlin/swift way of doing this.

https://docs.scala-lang.org/tour/pattern-matching.html

https://antonioleiva.com/when-expression-kotlin/

https://www.reddit.com/r/java/comments/7rgnei/jep_325_switch...

C# has seen a similar push to implement pattern matching, down to the use of `_` as discard. The first iteration of this feature in C# 7 is feature light, but it's a good start, and they've promised more to come. The team behind C# has become really good at getting over NIH and embracing new technologies and techniques while somehow preserving backwards compatibility and ergonomics. Anders Hejlsberg doesn't kid around.

Here's an example cribbed from an official MSFT blog [0]:

    public static int Count<T>(this IEnumerable<T> e)
    {
        switch (e)
        {
            case ICollection<T> c: return c.Count;
            case IReadOnlyCollection<T> c: return c.Count;
            // Matches concurrent collections
            case IProducerConsumerCollection<T> pc: return pc.Count;
            // Matches if e is not null
            case IEnumerable<T> _: return e.Count();
            // Default case is handled when e is null
            default: return 0;
        }
    }

EDIT:

Little-known fact: C# actually does have discriminated unions, and has had for a long time (from the start?) in the form of the `Exception` base class. In fact, pattern matching in C# can be "pulled off" (read: hacked together as a proof-of-concept) without the changes from C# 7 by simply using the extended catch syntax:

    class MyType1 : System.Exception
    { /* ... */ }

    class MyType2 : System.Exception
    { /* ... */ }

    void foo()
    {
        throw something ? new MyType1() : new MyType2();
    }

    void bar()
    {
        try
        {
            foo()
        }
        catch (MyType1 mtype)
        {
            //take type-specific action here
        }
        catch (MyType2 mtype)
        {
            //take type-specific action here
        }
        catch (Exception _)
        {
            //the _ was optional, but this is the `default` block
        }
    }

(And tuples, ADTs ah the list goes on..)

Concise AND expressions (eg "case UP, DOWN -> 1;"): +1

Using keyword 'break' instead of 'return': -1

But it's makes language more complicated and what is more important - it makes harder to refactor, especially via IDE. So my opinition: we don't need this and this doesn't have any value besides marketing.

The -> is not a good idea and break <something> should be return <something>. The -> throw e; "sugar" is just ridiculous!

Here, “int result = switch...” seems nice for that one situation, “until it isn’t” (and in my experience these “until” events can come as soon as the very next time you have to maintain the thing). Oh, wait: I actually want to log something in one of the cases in addition to the assignment but since the entire thing is a fancy assignment expression now I have to rewrite 90% of it to add a glorified print statement for one of them!?

And it’s not just Java. In “new” C++ for instance, the highly-specialized syntax for loop iteration is nice but it has the same problem: sometimes the change you’re making does need iterators, unusual increment points, etc. and you end up peeling apart everything that was supposed to be so helpful and rewriting way more than you should need to.