Sugar is expensive

[davidmarkclements]

you seem to be trying to "fix" the language, at the cost of unnecessary overhead in both compute time and your time.

function fact (input) {
  switch (input) {
    case 0: return 1
    default: return (n) => n * fact(n-1)
  }
}

function protocols ({useGit, useSSH, useHTTP, useHTTPS}) {
  switch (true) {
    case useGit && useSSH: return 'git+ssh'
    case useGit && useHTTP: return 'git+http'
    case useGit && useHTTPS: return 'git+https'
    default: return 'unsupported'
  }
}

['hey.com', 'fg@plop.com', 'fg+plop@plop.com', 'wat'].filter((email) => !/\S+@\S+\.\S+/.test(email))

[phillipCouto]

You can say that about a few features of ES2015 when they were just polyfills in tools like Babel and Tracur but yet these features are now gaining engine support of optimized code generation so why would this be considered a waste of time if developers see a value in it. ES2015, 2016, 2017 are all examples of sugar to "fix" the existing javascript language by making it more modern.

[arturkulig]

Try to match

"ok"
["error","shit went wrong"]

with switch.

[davidmarkclements]

@phillipCouto native syntax extensions are a different story - they gain engine support because they're driven by the TC39. That said, some of the features are actually detrimental both in overhead (this is measurable) and engineering patterns (this is opinion) - (see http://npm.im/es2020 and http://npm.im/es2040)

If you see value, and that value outweighs the cost (in terms of developer learning and performance overhead) then that's cool

@arturkulig

Interesting way to construct an error

function howAreWe (thing) {
  switch (true) {
     case thing === 'ok': return ok()
     case isErrArray(thing) && thing[1] === 'shit went wrong': return shitWentWrong()
     default: return somethingElse()
  }
}

function isErrArray (thing) {
  return Array.isArray(thing) && thing[0] === 'error'
}

But it doesn't have to be a switch (the same way you're two values don't have to use match-when)

function howAreWe (thing) {
  return thing === 'ok' ? 
    ok() :
    (isErrArray(thing) && thing[1] === 'shit went wrong' ? shitWentWrong() : somethingElse())
}

[arturkulig]

@davidmarkclements You got me. It surely is correct, but I had something slightly else in mind and should have be more clear. I should have add "in equally readable manner".
Think of more various data types and gotchas like null-checking before getting into object properties. It will work surely, but readability drops significantly at least in comparison to pattern matching. Also - you require additional function so case it not too long.
Although I still think it is valuable tool and I'll probably use it, you are making valid point that should be reminded in docs - that this is tool for heavy lifting; that in simpler cases it can be replaced with simple switch.

[phillipCouto]

@davidmarkclements I totally agree with your points in your posts, the issue I had especially was just the reference of wasting time. Is this solution a performant one? Definitely not. The implementation spends time serializing and deserializing objects which in hot code paths would be devastating but what I love about these projects is that it can open peoples minds to possibilities. For both sides, either to support it or not. Example being you providing more efficient native solutions that is close to similar readability.