Discuss
  • Proposal: enhanced case clause

Proposal: enhanced case clause

# Sm In (6 years ago)

Before read: I'm not a native. so I may used some unnatural expression, or non-sense sentence. I feel so sorry for this. :(

preface

currently, a switch statements's case claues compares equality between it's value and the switch statements's input value. just like this:

switch(x) {
  case 1:
    console.log('x is 1');
    break;
  case 2:
    console.log('x is 2');
    break;
  default:
    console.log('x is not 1 and 2');
}

As I know, many books teaches people to use switch statement when there is many cases for one value. like above example.

But, sadly, In many case include above one, the if statement is better than switch statement. the above example can be replaced by if statement like blow.

if (x === 1) {
  console.log('x is 1');
} else if (x === 2) {
  console.log('x is 2');
} else {
  console.log('x is not 1 and 2');
}

code which uses if statement is shorter then switch statement, but we know shorter code is not good at anytime, I mean, sometimes, loger but more meaningful code is better then shorter one. So, about that simple example, some people would say "code which uses if statement is better" and other would say "no, code which uses switch statement is better". yes, this far, people could have different opionion about better example.

but, let's check more complex example. what about checking value's properties? maybe it is number, "checking value's properties" can be cheacking is it integer or real number.

I think code would be better then my english sentence. here is an example with if statement.

if (x % 1) {
  console.log('x is real number');
} else {
  console.log('x is integer');
}

then, here is above example by switch statement. since switch statement compares equality between it's value and the case clause's input value.

switch(true) {
  case x % 1 !== 0:
    console.log('x is real number');
    break;
  default:
    console.log('x is integer');
}

yes, this code is dirty. also it containes redundant codes(which required by syntax, but in view of human(who reads code), something like true or x is useless one). So, I propose a new syntax for switch statement in order to reduce some redundant codes from switch statement.

new syntax for switch statement

here is an example of the new syntax that works same as above example

switch(x) {
  case % 1 !== 0:
    console.log('x is real number');
    break;
  default:
    console.log('x is integer');
}

yes, this is it. more meaningful then before.

anyway, let me explain detailed sementic.

when case clause's expression's most left operend is omitted, switch's input value(in above example, x is it) gose to that place(omitted operend place!)

I will finish my email by showing one more example to you. thank you for reading this and have a nice day!

switch(x) {
  case > 10:
    console.log('x is bigger then 10');
    break;
  case > 5:
    console.log('x is bigger then 5, but smaller then 10');
    break;
  case > 0:
    console.log('x is bigger then 0, but smaller then 5');
    break;
  default:
    console.log('x is smaller then 0');
}
# Jordan Harband (6 years ago)

Rather than investing more in switch statements, tc39/proposal-pattern-matching may be more compelling :-)

# Sm In (6 years ago)

Thank you for answer, I've checked thart proposal before. As I know, proposal-pattern-matching contains guards(which checkes value's property)

Yes, this proposal's new sementic seems duplicate pattern match's guard. But, As I know, the guard can be associcated with only one pattern. here is an example from proposal-pattern-matching:


const res = await fetch(jsonService)case (res) {
  when {status: 200, headers: {'Content-Length': s}} -> {
    console.log(`size is ${s}`)
  }
  when {status: 404} -> {
    console.log('JSON not found')
  }
  when {status} if (status >= 400) -> {
    throw new RequestError(res)
  }
}

Okay, looks fine, but how about when we want to send different error when error code is 5xx? do I have to do this?


const res = await fetch(jsonService)case (res) {
  when {status: 200, headers: {'Content-Length': s}} -> {
    console.log(`size is ${s}`)
  }
  when {status: 404} -> {
    console.log('JSON not found')
  }
  when {status} if (status >= 400 && status < 500) -> {
    throw new RequestError(res)
  }
  when {status} if (status >= 500) -> {
    throw new InternalServerError(res)
  }
}

Humm, this looks odd, we duplicate when {status} twice! so, I can say: "pattern matching is good at checking value's structure. checking it's property is small option."

I don't know which one is better choice, pushing this proposal or adding this problem as issue to proposal-pattern-matching(they have some plans for future, and this can be merged into there). and creating genenral syntax or creating specific syntax in order to solve problem.

please help me to figure out in this problem :))

# Isiah Meadows (6 years ago)

I'd say the best way is to just file an issue.

Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com

# Sm In (6 years ago)

Good Idea, thank you for answer, I will do it :)

2019년 1월 20일 (일) 오후 6:01에 Isiah Meadows <isiahmeadows at gmail.com>님이 작성: