proposal-pattern-matching: Disallow unreachable clauses

I would propose to ensure that no other clause is after the else one since it should be the last (probably throwing an error at that point).

Currently nothing in the spec disallow this:

match (4) {
  1: "one",
  else: "else",
  4: "abandoned"
}

Since the 4 cause will never match, I don’t see why the developers could be able to write it. That’s also a behavior linter will need to implement for case exhaustiveness.

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 4
Comments: 18 (5 by maintainers)

Most upvoted comments

I disagree that throwing an error only for else would be “amateurish”.

Throwing on no errors when we could throw on some, however, might be. We should throw on everything that’s practical and possible to throw on, and not being able to catch “everything” doesn’t diminish the value of that in the slightest.

ljharb on Nov 24, 2017

@xtuc I would rather make a new one where new discussion happens in terms of the new format, since it might be confusing to scroll through an issue and see mostly the old grammar if you’re trying to grok the new one. Do you think that’d be enough? I’m happy enough to open a new issue that does this and gives a summary of the requirements in the new context, too (or you could?).

zkat on Mar 26, 2018

Looking at the JS language, both points of views seem valid to me. We cannot write an else before an if, but we can make a case in a switch after a default. By reading eslint most used rules, it seems that JS never took a stand for one side or the other. My point is it seems there is no philosophy or JS culture going against any of you and it stays as only a pragmatic engineering decision.

Disallowing patterns after else:

Does it disallow legit use cases? No.
Does it change the performance? Probably not a lot.
Does it save some bugs? A few, except for tooled developers.
Can it be done better by another tool? Certainly.
Does it make the specs more complicated to implement? Not a lot in my opinion, but TBD.
Does it make the specs more complicated to understand/learn? Not really.
Can it be superseded by something better? TBD
Will it introduce compatibility concern long term? No.

I may have missed some points in the discussion, and I don’t want to misrepresent your stand. You fundamentally agree on facts, and reach similar conclusions.

If @leonardiwagner’s suggestion of better matcher is doable, I think we agree it’s better.
If not, I’m sure the proposition of @xtuc is actually a step towards we can all agree.

So if I understood, the question is for Benedikt and other implementers right?

baptistemanson on Nov 30, 2017

@ljharb you got my point.

This discussion isn’t about how to write the else clause but rather if we allow other clauses after it.

xtuc on Nov 24, 2017

If there is a pattern that can be determined for all values to be unreachable, then yes, I would expect an error. Why would we want to permit someone to write something that’s verifiably wrong?

ljharb on Nov 24, 2017