Proposal-pattern-matching: Disallow multiline MatchExpressionPattern

Created on 22 Nov 2017 · 4Comments · Source: tc39/proposal-pattern-matching

The spec is currently allowing multiple lines in the MatchExpressionPattern since it includes ObjectMatchPattern and ArrayMatchPattern.

In some cases It seems to me to impact the readability of the code, for example:

let detail = match(test) {
    {
        name,
        birthday: {year},
        birthplace: {country},
    }: name + "(" + year + ")" + " from " + country
}

On the other hand, puting this pattern on one line would be even less readable but I hope that it will force the developer to refactor it somehow. Thus it will be harder to do bad things.

What do you think?

Source

xtuc

👎8

Most helpful comment

I think it could occur a warning of multiline pattern, maybe it can be disallowed in eslint or something like this. But I think we do not have to force programmer don't write like this.

vincentdchan on 22 Nov 2017

👍6

All 4 comments

I think it could occur a warning of multiline pattern, maybe it can be disallowed in eslint or something like this. But I think we do not have to force programmer don't write like this.

vincentdchan on 22 Nov 2017

👍6

No, it's not up to you to decide the code style of others

TomMarius on 22 Jan 2018

This restriction would be somewhat of a break from destructuring, which permits newlines here. What is different about this case?

littledan on 22 Jan 2018

Hey y'all! #65 has gotten merged, and a lot of issues have become irrelevant or significantly changed in context. Because of the magnitude of changes and subtle differences in things that seem similar, we've decided to just nuke all existing issues so we can start fresh. Thank you so much for the contributions and discussions and feel free to create new issues if something seems to still be relevant, and link to the original, related issue so we can have a paper trail (but have the benefit of that clean slate anyway).

That said, I'm with @littledan on this, and think this sort of restriction would create some impedence mismatch as far as current semantics around destructuring goes -- and I think it's pretty important to preserve the analogy between standard destructuring and match-destructuring.