Discuss
  • Proposal: switch expressions

Proposal: switch expressions

# David Koblas (6 years ago)

After looking at a bunch of code in our system noted that there are many cases where our code base has a pattern similar to this:

     let category = data.category;

     if (category === undefined) {
       // Even if Tax is not enabled, we have defaults for incomeCode
       switch (session.merchant.settings.tax.incomeCode) {
         case TaxIncomeCode.RENTS_14:
           category = PaymentCategory.RENT;
           break;
         case TaxIncomeCode.INDEPENDENT_PERSONAL_SERVICE_17:
           category = PaymentCategory.SERVICES;
           break;
         case TaxIncomeCode.INDEPENDENT_PERSONAL_SERVICE_17:
           category = PaymentCategory.SERVICES;
           break;
       }
     }

I also bumped into a block of go code that also implemented similar patterns, which really demonstrated to me that there while you could go crazy with triary nesting there should be a better way.  Looked at the pattern matching proposal and while could possibly help looked like it was overkill for the typical use case that I'm seeing. The most relevant example I noted was switch expressions from Java.  When applied to this problem really create a simple result:

     const category = data.category || switch (setting.incomeCode) {
       case TaxIncomeCode.RENTS_14 => PaymentCategory.RENT;
       case TaxIncomeCode.ROYALTIES_COPYRIGHTS_12 => 

PaymentCategory.ROYALTIES;
       case TaxIncomeCode.INDEPENDENT_PERSONAL_SERVICE_17 => 

PaymentCategory.SERVICES;
       default => PaymentCategory.OTHER;
     }

Note; the instead of using the '->' as Java, continue to use => and with

the understanding that the right hand side is fundamentally function.  So similar things to this are natural, note this proposal should remove "fall through" breaks and allow for multiple cases as such.

     const quarter = switch (foo) {
       case "Jan", "Feb", "Mar" => "Q1";
       case "Apr", "May", "Jun" => "Q2";
       case "Jul", "Aug", "Sep" => "Q3";
       case "Oct", "Nov", "Dec" => { return "Q4" };
       default => { throw new Error("Invalid Month") };
     }

Also compared this to the do expression proposal, it also provides a substantial simplification, but in a way that is more consistent with the existing language.  In one of their examples they provide an example of the Redux reducer redux.js.org/basics/reducers#splitting-reducers -- this would be a switch expression implementation.

     function todoApp(state = initialState, action) => switch 
(action.type) {
       case SET_VISIBILITY_FILTER => { ...state, visibilityFilter: 

action.filter };
       case ADD_TODO => {
           ...state, todos: [
             ...state.todos,
             {
               text: action.text,
               completed: false
             }
           ]
         };
       case TOGGLE_TODO => {
           ...state,
           todos: state.todos.map((todo, index) => (index === 

action.index) ? { ...todo, completed: !todo.completed } : todo)
         };
       default => state;
     }
# N. Oxer (6 years ago)

This would be covered by do expressions tc39/proposal-do-expressions. You could just do:

const category = do {
  switch (...) {
    ...
  };
};
# David Koblas (6 years ago)

I quite aware that it’s covered in do expressions. Personally I find do expressions non-JavaScript in style and it’s also not necessarily going to make it into the language.

Hence why I wanted to put out there the idea of switch expressions.

# Jordan Harband (6 years ago)

Additionally, tc39/proposal-pattern-matching - switch statements are something I hope we'll soon be able to relegate to the dustbin of history.

# David Koblas (6 years ago)

Jordan,

One question that I have lingering from pattern matching is why is the syntax so different? IMHO it is still a switch statement with a variation of the match on the case rather than a whole new construct.

Is there somewhere I can find a bit of discussion about the history of the syntax decisions?

# Jordan Harband (6 years ago)

Pattern Matching is still at stage 1; so there's not really any permanent decisions that have been made - the repo theoretically should contain rationales for decisions up to this point.

I can speak for myself (as "not a champion" of that proposal, just a fan) that any similarity to the reviled and terrible switch is something I'll be pushing back against - I want a replacement that lacks the footguns and pitfalls of switch, and that is easily teachable and googleable as a different, distinct thing.

# David Koblas (6 years ago)

Jordan,

Thanks for taking time to read and provide thoughts.

I just back and re-read the pattern matching proposal and it still fails on the basic requirement of being an Expression not a Statement.  The problem that I see and want to address is the need to have something that removes the need to chain trinary expressions together to have an Expression.

This is unmaintainable --

const x = v === 'foo' ? 1 : v === 'bar' ? 3 : v === 'baz' ? 6 : 99;

This is maintainable, but is less than ideal:

let x;

switch (v) {    case "foo":      x = 1;      break;    case "bar":      x = 3;      break;    case "baz":      x = 6;      break;    default:      x = 99;      break;    }

Pattern matching does shorten the code, but you have a weird default case and also still end up with a loose variable and since pattern matching is a statement you still have a initially undefined variable.

let x;

case (v) {      when "foo" -> x = 1;      when "bar" -> x = 3;      when "baz" -> x = 6;      when v -> x = 99;    }

Let's try do expressions, I'll leave people's thoughts to themselves.

const x = do {      if (v === "foo") { 1; }      else if (v === "bar") { 3; }      else if (v === "baz") { 6; }      else { 99; }    }

Or as another do expression variant:

const x = do {      switch (v) {        case "foo": 1; break;        case "bar": 3; break;        case "baz": 6; break;        default: 99; break;      }    }

And as I'm thinking about switch expressions:

const x = switch (v) {      case "foo" => 1;      case "bar" => 3;      case "baz" => 6;      default => 99;    }

What I really like is that it preserves all of the normal JavaScript syntax with the small change that a switch is allowed in an expression provided that all of the cases evaluate to expressions hence the use of the '=>' as an indicator. Fundamentally this is a very basic concept

where you have a state machine and need it switch based on the current state and evaluate to the new state.

const nextState = switch (currentState) {       case ... =>    }

# Isiah Meadows (6 years ago)

You're not alone in wanting pattern matching to be expression-based:

tc39/proposal-pattern-matching#116

Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com

Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com

# David Koblas (6 years ago)

Just for folks who might be interested, added a babel-plugin to see what was involved in making this possible.

Pull request available here -- babel/babel#9604

I'm sure I'm missing a bunch of details, but would be interested in some help in making this a bit more real.

# kai zhu (6 years ago)
# Naveen Chawla (6 years ago)

Isn't the best existing pattern an object literal?

const cases = { foo: ()=>1, bar: ()=>3, baz: ()=>6 } , x = cases[v] ? casesv : 99 ;

What does any proposal have that is better than this? With optional chaining feature:

const x = { foo: ()=>1, bar: ()=>3, baz: ()=>6 }[v]?.() || 99 ;

Do let me know your thoughts guys

# David Koblas (6 years ago)

Kai,

Thanks for the feedback and the real world example.

Most of my examples have been focused on simple cases.  The full example is something that would support the following style:

     const food = switch (animal) {
       case Animal.DOG, Animal.CAT => {
         // larger block expression
         // which spans multiple lines

         return "dry food";
       }
       case Animal.TIGER, Animal.LION, Animal.CHEETA => {
         // larger block expression
         // which spans multiple lines

         return "fresh meat";
       }
       case Animal.ELEPHANT => "hay";
       default => { throw new Error("Unsuppored Animal"); };
     };

The basic things that I'm focusing on are:

  • The evaluation of the switch is an expression that returns a value
  • The case statement doesn't fall through and supports multiple descriminators
  • Use arrow expressions to return values, these can be either simple values or blocks returning a value.
  • Syntax that is quickly recognizable with existing JS patterns
# David Koblas (6 years ago)

Naveen,

Thanks for your observation.  The example that I gave might have been too simplistic, here's a more complete example:

    switch (animal) {
    case Animal.DOG, Animal.CAT => {
        // larger block expression
        // which spans multiple lines

        return "dry food";
      }
    case Animal.TIGER, Animal.LION, Animal.CHEETA => {
        // larger block expression
        // which spans multiple lines

        return "fresh meat";
      }
    case Animal.ELEPHANT => "hay";
    default => { throw new Error("Unsupported Animal"); };
    }

While you give examples that would totally work.  Things that bother me about the approach are, when taken to something more complex than a quick value for value switch you end up with something that looks like this.


    function houseAnimal() {
        // larger block expression
        // which spans multiple lines

        return "dry food";
    }

    function wildCatFood() {
      // larger block expression
      // which spans multiple lines

      return "fresh meat";
    }
    

    const cases = {
      [Animal.DOG]: houseAnimal,
      [Animal.CAT]: houseAnimal,
      [Animal.LION]: wildCatFood,
      [Animal.TIGER]: wildCatFood,
      [Animal.CHEETA]: wildCatFood,
    }

    const food = cases[animal] ? cases[animal]() : (() => {throw new Error("Unsuppored Animal")})();

As we all know once any language reaches a basic level of functionality anything is possible.  What I think is that JavaScript would benefit by having a cleaner approach.

# Naveen Chawla (6 years ago)

Your last example would, I think, be better served by classes and inheritance, than switch.

Dogs are house animals which are animals Cheetas are wild cats which are animals

Each could have overridden methods, entirely optionally, where the method gets called and resolves appropriately.

The input argument could be the class name, from which it is trivial to instantiate a new instance and get required results.

Using a "switch" here forces you to group classes of objects together and then you don't get the 2nd, 3rd, 4th etc. levels of specialization that you might later want.

All thoughts on this are welcome. Do let me know

# Isiah Meadows (6 years ago)

Using a "switch" here forces you to group classes of objects together and then you don't get the 2nd, 3rd, 4th etc. levels of specialization that you might later want.

Sometimes, this is actually desired, and most cases where I could've used this, inheritance was not involved anywhere. Also, in performance-sensitive contexts (like games, which heavily use switch/case), method dispatch is far slower than a simple switch statement, so that pattern doesn't apply everywhere.

BTW, I prefer tc39/proposal-pattern-matching over this anyways - it covers more use cases and is all around more flexible, so I get more bang for the buck.

Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com

# David Koblas (6 years ago)

Isiah,

While the pattern-matching proposal does cover a much richer matching, it still doesn't target the issue of being a statement vs an expression.  Part of my initial motivation is that the evaluation of the switch returns a value, which pattern-matching doesn't resolve.

Very much enjoying the discussion,

# Isiah Meadows (6 years ago)

While the pattern-matching proposal does cover a much richer matching, it still doesn't target the issue of being a statement vs an expression. Part of my initial motivation is that the evaluation of the switch returns a value, which pattern-matching doesn't resolve.

That's still something a lot of people want to see end up in the proposal - in fact, tc39/proposal-pattern-matching#116 was filed by a TC39 committee member. I wouldn't dismiss the possibility of pattern matching expressions before then.

Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com

# Naveen Chawla (6 years ago)

I'm not sure that pattern matching handles deep levels of inheritance more elegantly than inheritance itself.

If there is a conceptual type hierarchy, then the ability to call "super", combine it with specialized functionality, etc. is a lot more manageable using localized, separated logic where you don't feel forced to read "other patterns" to understand whether your target functionality will resolve correctly. And hence, a lower chance of bugs.

As for performance, I'd have to see modern benchmarks. But it's not necessarily clear that pattern matching will be particularly fast either. I've done game programming with method overriding (Three.js uses it too throughout) and there is no notable performance hit from doing so. So I'm not clear where you have got this information from.

# Isiah Meadows (6 years ago)

I'm looking at Three.js's code base, and I'm not seeing any method overriding or abstract methods used except at the API level for cloning and copying. Instead, you update properties on the supertype. As far as I can tell, the entirety of Three.js could almost be mechanically refactored in terms of components instead of inheritance, without substantially modifying the API apart from a few extra .geometry/etc. property accesses when calling supertype methods. It's data-driven and almost ECS. (It uses .isObject3D, .isPerspectiveCamera, and similar brand checks, but those don't need to be inherited to work.)

Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com

# Naveen Chawla (6 years ago)

The entire renderers, cameras, meshes etc. hierarchy uses method inheritance and many of those methods are called during scene rendering (which is performance sensitive as it happens per frame). It would be unthinkable for it to use pattern matching or explicit code branching instead of method inheritance for type disambiguation during render, because it would explode the code as well as making it error prone due to initial cases potentially unintentionally swallowing up cases intended for later code branches (or unintentionally repeating code branches if the pattern-matching proposal doesn't have "else" behaviour, of which I'm not sure, but it if does, it suffers from the first problem anyway).

I'm curious where you got the idea that method invocation is "far" slower than explicit code branching?

# Isiah Meadows (6 years ago)

It would be unthinkable for it to use pattern matching or explicit code branching instead of method inheritance for type disambiguation during render

But it frequently does internally. For example:

Obviously, it exposes a data-oriented, object oriented API. And it does appear it's not exclusively conditionals:

However, I'm finding exceptions in its core and renderers, and it doesn't appear virtual dispatch is that broadly and pervasively used, even though it uses methods a lot.

* This seems like overkill when the diff between the two renderers in question 1, 2 consist of an extra method + 2 extra variables 3, 4, a few changed method invocations 5, 6, and the rest just due to a different name and a useless var.

I'm curious where you got the idea that method invocation is "far" slower than explicit code branching?

And in my experience, the speed difference in real-world performance-critical code is not unlike that microbenchmark and is sometimes even more drastic, especially if it's a linked list instead of just a simple array lookup.

I'd like to emphasize I'm specifically referring to the case where the engine can't reliably assume a single method receiver, i.e. when it has to fall back to dynamic dispatch.

Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com

# Naveen Chawla (6 years ago)

I don't think those benchmarks test exactly what we are talking about. They have a dictionary/array look up followed by method dispatch, vs switch case and execute. Removing the look up it would be: x.doStuff() vs switch(x.type).... Make sense? Don't have time to do it right now.

Logically I think the JS engine can make them perform identically, so even if benchmarks show something today, I would not be concerned for the future and so would prefer to opt for the paradigm that offers the best manageability, which I think is inheritance by a significant margin, in the cases mentioned. Other types of cases could of course be a whole different story.

# Isiah Meadows (6 years ago)

IIUC the "object dispatch integer"/"object dispatch string" benchmarks are the things you were referring to. Those simulate what the engine would see with virtual dispatch and completely different type maps, just without the source overhead of creating an entire class just for a little benchmark.

And also, engines won't be able to optimize them generally, because there could be infinitely many type maps, and after about 200 or so types, the switch statement ends up much slower.

Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com

# Naveen Chawla (6 years ago)

It "simulates" then does it for real, hence slower than just doing it (there is no need to simulate if we have the paradigm we are are trying to benchmark ready for us to just use). I'd be curious to see a direct benchmark comparison, but don't have time to set it up right now.

# Isiah Meadows (6 years ago)

By "simulating", I meant doing something that was functionally equivalent. If you wanted a direct equivalent, just replace all instances of {keyN: true, print: function () { ... }} with new class { constructor() { this.keyN = true } print() { ... } } in the benchmarks, and you've got something that's exactly equivalent. And no, that won't be any faster, because in either case, with object literals or with immediately-invoked classes, the engine is working with a different set of type maps for each type, so the only variable here is whether print is own or prototype and whether the prototype is Object.prototype or a unique object. If anything, the class variant would be slower because of the indirection.

Here's a couple fixed benchmarks with clearer test names:

In both cases, method dispatch is about 10-20% slower than the corresponding switch/case, and is only marginally (< 5%) faster than dynamic string property dispatch. I've gotten these results running both benchmark suites about 10 times each and even in the one statistical outlier I had where everything ran slower, method dispatch still was listed as slower than switch/case across the board and roughly equal to dynamic string property dispatch.

One last thing: could you please quit arguing semantics?

Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com