2021-09-02 [18:46:43.0437] Continue bare if issue: One reason I worry about it, is bare if clauses have different semantics with normal code, which add the risk of refactoring. For example, for some reasons all `when` clauses were removed, and only bare if clauses left, so someone may just remove the `match` (because it's now meaningless), and if they forget to "fix" the if clauses to if/else if , the semantics changes though they are still valid syntax... [21:55:19.0506] i don't think that's a plausible scenario [21:55:34.0339] `match (x) { if () { } }` isn't meaningless because it's an expression with `do {}` semantics, and it has a default `else` [21:55:40.0957] so if they remove the `match` they'll get a syntax error in expression position - and in statement position, it would work identically (except for the "throw" case for the "no match" scenario) [21:55:47.0292] * so if they remove the `match` they'll get a syntax error in expression position [21:56:01.0873] * `match (x) { if () { } }` isn't meaningless because it's an expression with `do {}` semantics [21:56:09.0025] * so if they remove the `match` they'll get a syntax error in expression position - and in statement position, it would work identically. [21:56:23.0134] * so if they remove the `match` they'll get a syntax error in expression position - and in statement position, it would work identically (except for the "throw" case for the "no match" scenario) [21:56:29.0954] * `match (x) { if () { } }` isn't meaningless because it's an expression with `do {}` semantics, and it has a default `else` [21:56:54.0052] iow, just like `() => x` isn't a refactoring hazard because "what if somebody removes the `() =>`, this isn't either [08:29:16.0691] ljharb: tho `match() { if(x){} if(y){} else{} }` will change behavior if the match was in statement position and then gets removed - both `if`s will execute, rather than the second being skipped if the first is true, and the `else` can execute alongside the first `if` as well [08:29:44.0541] I agree this isn't a significant issue to worry about, but wanted to make sure HE Shi-Jun's concern was clear. ^_^ [08:35:29.0235] good clarification, but i don’t think it changes anything [08:46:50.0542] I agree - it's the same level of refactoring hazard as `()=>x` to `x`. 2021-09-03 [23:20:45.0406] I'm confused, why someone want to change `() => x` to `x` ? They are totally different. [23:23:21.0507] On the other side, people may want to remove `match` because `v` in `match(v) { if (x) {} if (y) else {} }` is never used, and may make mistake. [03:35:47.0117] Oh, do u mean T.C.P? Yeah, it's a bit like it. 2021-09-04 [08:39:50.0488] removing `match` also makes it something totally different [08:40:07.0548] someone who doesn't understand that, might also not understand that `() =>` makes it something totally different [08:41:46.0389] * someone who doesn't understand that, might also not understand that `() =>` makes it something totally different [08:42:08.0508] iow i think that there has to be *some* threshold of understanding we take for granted, otherwise everything's confusing 2021-09-07 [01:16:13.0022] `()=>` doesn't make it "totally different", most things just work, the only things changed are control flow things (`return`, `break`, `continue`, `await`), and if u wrap the code with `() =>`, most wrong usage of them will report as syntax error, so people only need to care about `return`, and js programmers already know that from the start day of js because the existence of anonymous functions. Changes of `if` is totally different. I could accept that only it could produce enough syntax errors to avoid misuse. [08:03:30.0332] it makes it a function instead of whatever the value is. Having to invoke it is indeed very different