On Friday, 31 March 2023 at 23:52:29 UTC, Steven Schveighoffer wrote:

switch(x)
{
  case 0:
    doCase0;
    break;
  case 1:
    doCase1;
    break;
}

How often does anyone use "default: break"?

i pretty much exclusively use "default: assert(0)"

If i have cases that do nothing I still put them in, default is there to catch stuff ive forgoten.

On Saturday, 1 April 2023 at 07:32:28 UTC, claptrap wrote:

If you are a lazy (actually talented) programmer 😀

In fact, if you use enums, the compiler will warn you with the comment in the code.
But this way program produces 2 lines of output likes this:

I learned this method from Walter in Dconf'22. Remove the toggle-comment at the beginning of the final to try.

enum Weather { hot, humid, cold,
             sunny, windy, cloudy,
         drizzling, rainy, foggy
}

string shallWeGo(Weather w)
{
    //final switch(w) {/*
    switch(w) {
       default: return home();//*/
       case Weather.hot:
         w.writeln(": ", 1);
         return sea();
       case Weather.humid:
         w.writeln(": ", 2);
         return cave();
       case Weather.sunny:
         w.writeln(": ", 3);
         return beach();
       case Weather.cloudy:
         w.writeln(": ", 3);
         return home;
    }
}

import std.stdio;
void main()
{
    auto choice = Weather.humid;
    choice.shallWeGo().writeln;
}

auto sea() => "";
auto home() => "";
auto cave()
    => "I'm in Silifke Asthma Cave";
auto beach() => "";

/* Without the final keyword you will get a compilation error:
onlineapp.d(8): Error: missing cases for `enum` members in `final switch`:
onlineapp.d(8):        `cold`
onlineapp.d(8):        `windy`
onlineapp.d(8):        `drizzling`
onlineapp.d(8):        `rainy`
onlineapp.d(8):        `foggy`
*/

SDB@79

On Friday, 31 March 2023 at 15:20:41 UTC, Steven Schveighoffer wrote:

On the one hand, it's not nearly always that I wish to break in the default case, often I want to assert(0) instead. This idea would encourage not checking for erroneous states, which is worse than usual since this check is free or almost free in runtime.

On the other hand, I sure like short code and it'd also be in line with what C and C++ do.

On balance, I maybe prefer current behaviour. D in general places greater emphasis on hardening the code against bugs than most languages do. It's not Ada or Rust, but still. If we were talking about a typical quick-and-dirty scripting language, the change could fit it better, but it's not as good for D IMO.

On 3/31/23 11:20 AM, Steven Schveighoffer wrote:

Thanks for all the replies and discussion.

I have realized from all of this that there is a major difference between if and switch which justifies the requirement: switch can only do single-value comparison. I.e. it has to be the equivalent of if(a == b), whereas if can cover any number of cases or patterns based on boolean logic and comparisons. This makes it a lot easier to cover all the cases you need in one go.

switch on the other hand, can only cover the cases you specify. In something like an int or even a byte, that means full coverage is unwieldy or near impossible. Even with case range statements, those actually just get expanded to all the intermediate cases. So forgetting go cover cases is much more likely.

So I withdraw the suggestion. It also gives me a much better response to "why does D do this?"

-Steve

On Friday, 31 March 2023 at 15:20:41 UTC, Steven Schveighoffer wrote:

I rarely use switch at all. Most of the time, it's too verbose to my taste, and has little benefit compared to a chain of if-else-if. On top of that, I pause to ponder what is the Right(TM) indentation style.

When I do use switch -- or a chain of if-else-if for that matter -- it often ends with a default case with assert(false) or similar. Or it should -- so, I do have a use for the default being required.

That said, given the verboseness of switch, I see a valid reason to question the current state.

Ivan Kazmenko.

On Friday, 31 March 2023 at 15:20:41 UTC, Steven Schveighoffer wrote:

(This doesn't seem like that much of a radical idea, considering that this is the case in functional languages, right?)

One small observation, you don't need to add break; before }. (The compiler doesn't emit warnings on missing break, but on fall-through, and reaching } isn't a fall-through.) Sometimes I add a comment explaining why the default case does nothing, instead of raising an exception or something like that.