Proposal: switch expressions

[Jordan Harband]

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.

On Mon, Feb 25, 2019 at 12:42 PM David Koblas <david at koblas.com> wrote:

> 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?
>
> --David
>
>
> On Feb 25, 2019, at 12:33 PM, Jordan Harband <ljharb at gmail.com> wrote:
>
> Additionally, https://github.com/tc39/proposal-pattern-matching - switch
> statements are something I hope we'll soon be able to relegate to the
> dustbin of history.
>
> On Mon, Feb 25, 2019 at 6:01 AM David Koblas <david at koblas.com> wrote:
>
>> 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.
>>
>> --David
>>
>>
>> On Feb 25, 2019, at 5:28 AM, N. Oxer <blueshuk2 at gmail.com> wrote:
>>
>> Hi,
>>
>> This would be covered by do expressions
>> <https://github.com/tc39/proposal-do-expressions>. You could just do:
>>
>> ```js
>> const category = do {
>>   switch (...) {
>>     ...
>>   };
>> };
>> ```
>>
>> On Sun, Feb 24, 2019 at 10:42 AM David Koblas <david at koblas.com> wrote:
>>
>>> 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
>>> https://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;
>>>      }
>>>
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190225/b9bae645/attachment-0001.html>