Why need break for each case label in a switch statement

[Usagi Ito ( @USAGI_WRP )]

Hi, folks.

The current dart implements need break statement for each case label
in a switch statement. And, throw the FallThroughError exception in a
run-time if omit a break at a case label.

Why we need break statement for each case label in a switch statement?
Of course, It need if the language has a semantic for it. But, the
Dart language is disallow a fall-through in the switch statement
originally. Thus, we hasn't reason for write a break statement for an
each case label. It's a pain only to many programmers.

I think, the Dart language specification is not need a break statement
in a switch statement if it disallow fall-through. And, I think
better, it should change to a compile-time error from a run-time
exception throwing at the same time.

What do you guys think?

thanks.

[灵剑子]

it allow empty case clause Fall-Through.

but i think the case of go maybe better.

golang:
switch xxxxx{
case v1,v2:
case v3:

}

On Mar 17, 3:27 pm, "Usagi Ito ( @USAGI_WRP )"

[poltomb]

I agree with this, if you are only allowing empty fall through, why
not separate multiple cases with commas on the same line. It is
cleaner syntax and is a heck of a lot more intuitive than only
allowing empty case fall-through. One (good) side effect is that
break statements are no longer necessary at the end of a case section,
but could be explicit if desired.

[Mark Bennett]

This is another +1 for this suggestion, as requiring breaks has been a
source of hard to find errors in my experience.

For anyone intereseted, I believe this is the item for this request in
the Dart issue tracker:

http://code.google.com/p/dart/issues/detail?id=2047&q=case%20break&colspec=ID%20Type%20Status%20Priority%20Area%20Owner%20Summary

[Ladislav Thon]

I think that C-style switch with fall-through and breaks needs to burn in hell. This is the case where we need slightly unfamilliar syntax, to make it absolutely clear that there is no fall-through. Some proposals were already mentioned.

And if Dart is ever going to get pattern matching, then get rid of switch completely and replace it with match.

LT

[Usagi Ito ( @USAGI_WRP )]

> golang's switch

I think better switch-beak that the golang than the current Dart. at
least, It's smart and compact. thanks for your sharing.

> the Dart issue tracker:
> http://code.google.com/p/dart/issues/detail?id=2047&q=case%20break&co...

it's nice issue! let's go to the issue tracker, and join the
discussion.

> pattern matching

It's very nice. I like a "pattern match" pattern in the haskell, the
erlang or similar. I'm glad that it will be implement to the Dart.

but, I'm worry that users(as like a C-style especially) can accept it
easy. thus, I think need switch pattern syntax for them. but, I think
they are not need complexity switch pattern with fall-through.

Therefor, I think unnecessary a fall-through, and it will not require
the break statement for the Dart.

> C-style switch with fall-through and breaks

It's evil, but it had semantics and effect with history in the C, C++
or similar. but, it's not require the Dart as the new language. ( I
also felt the same thing to the C#. enough already.)

Thanks for all.

[Lasse R.H. Nielsen]

On Mon, Mar 19, 2012 at 20:42, Mark Bennett <mark.f....@gmail.com> wrote:
> This is another +1 for this suggestion, as requiring breaks has been a
> source of hard to find errors in my experience.

The break requirements were for your protection.

But seriously, the reason for requiring breaks isn't that it's better,
but that it catches code that expects cases to fall through. People
are coming to Dart from languages with similar looking switch
statements with fallthrough. They might not realize that Dart doesn't
have fallthrough, and write code that expects it.
Without the break (or any other termination) requirement, code that
expected a fallthrough would not get any immediate error - the
following case would just not be executed. That would be a
hard-to-find error, whereas throwing a "case fallthrough" exception on
the correct source line should be easier to fix.

In the long run, it's possible (I can't say if it's probable) to
remove the requirement without affecting correct programs.

/L
--
Lasse R.H. Nielsen
l...@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K -
Denmark - CVR nr. 28 86 69 84

[Jay Young]

No, Lasse, your fall-throughs are already dead.

[Peter Ahé]

Ha ha! I had to think about that for a while, but I have only seen
that movie 10 times.

Cheers,
Peter

[Louis Wasserman]

One of the alternatives I've always liked would be having to give an explicit "continue" if deliberate fall-through was desired, instead of having to explicitly break if it wasn't desired.

Louis Wasserman
wasserm...@gmail.com
http://profiles.google.com/wasserman.louis

[Mark Bennett]

Totally agree Louis.

Though keeping a syntax familiar to JavaScript and Java developers is important, this is one case where newer languages seem to be migrating towards explicit continues rather than explicit breaks. This is the strategy taken by C# and CoffeeScript.

Given that it's generally understood that most developers write switch cases which end with a break the majority of the time, and that many new developers struggle to understand the implicit continue, I think there is a strong case to be made for adopting implicit breaks in Dart. Having made this transition personally with CoffeeScript I can tell you it's not as shocking as you would think and feels much more natural once you begin using it.

The big factor I can't speak to is the impact on the compiler and interpreter when switching to an implicit break from an implicit continue.