On Fri, Mar 31, 2023 at 11:20:41AM -0400, Steven Schveighoffer via Digitalmars-d wrote: [...]
> But we have such a thing, in the `default:` case requirement.
> 
> In my code, it happens quite a bit that I throw an exception in the default case, or return something, but there's still a lot of `default: break;` code in there.
[...]
> How much does this rule help you, vs. annoy you?
[...]

It annoys me. It's verbose and ugly.  But OTOH, I'm also thankful for it, because it has actually helped me catch bugs in my code on a few occasions -- when I forgot to write the default case.

So I dunno, I'm on the fence about this.  Maybe if there was a less verbose way to indicate that the missing case was intentional?


T

-- 
Written on the window of a clothing store: No shirt, no shoes, no service.

On 3/31/23 17:20, Steven Schveighoffer wrote:
> Imagine if every `if` statement required you to write an `else` clause, even if it was empty. The idea would be, that you have to affirmatively attest that you didn't want to have a special case for when it didn't match the condition.
> 
> How fast do you think that everyone would run screaming for the exits?
> 
> But we have such a thing, in the `default:` case requirement.
> 
> In my code, it happens quite a bit that I throw an exception in the default case, or return something, but there's still a lot of `default: break;` code in there.
> 
> But consider a few things here:
> 
> 1. I have `final switch` at my disposal whenever I need it, which allows me to avoid `default:` and is really meant for "I want to make sure I handle everything"
> 2. If you forget to return something, or throw an exception, the compiler will still let you know (i.e. some code paths don't return a value). This counts for the majority of places where I have a `default` case that's not just `break;`.
> 3. I know in my experience (yours may vary) that when I forget to include a default, it's usually because I forgot to include `default: break;`. So the rule hasn't really helped me avoid bad code.
> 4. `switch` is already bloated enough with the requirement for `break` or `goto` between cases.
> 
> If we wanted to relax this requirement it's actually an easy change -- no currently-compiling code will break.
> 
> Why not? How much does this rule help you, vs. annoy you?
> 
> -Steve

I prefer the current behavior.

On 3/31/23 2:40 PM, Sebastiaan Koppe wrote:
> On Friday, 31 March 2023 at 18:30:27 UTC, Steven Schveighoffer wrote:
>> Do you feel the same about if statements without `else`? Why is it different?
>>
> 
> If statements are rather binary, and it is easy to understand the two paths.
> 
> Switches often have more than 2 cases, and its easier to forget one.

Complex if conditions are not "binary". I find it just as easy to forget a clause in an if statement that does the right thing.

> 
> Also consider refactoring. With switches I might add or rename or replace one of the values, which doesn't happen with if statements.

If you "forget a case statement", or refactor it, forcing you to write `default: break;` doesn't fix that.

-Steve

On Friday, 31 March 2023 at 21:04:52 UTC, Timon Gehr wrote:
> I prefer the current behavior.

Me too.
If you don't like default, use enums and final switch.
If you use switch over intergers, very often some values are not covered with cases, so even if you don't expect them to occur, it can happen. Therefore having a default case (that e.g. throws) is useful most of the time.

On Friday, 31 March 2023 at 21:24:25 UTC, Steven Schveighoffer wrote:
> If you "forget a case statement", or refactor it, forcing you to write `default: break;` doesn't fix that.
>

Whenever I do write then, I do it reluctantly and mostly as a last resort.

Having the default be open-endedness means I don't get reminded about that ugly detail anymore.

Of the two evils, I prefer the explicit one.

On 4/1/23 01:52, Steven Schveighoffer wrote:
> 
> The open-endededness is not that you forgot a case, it's that you didn't care about that case, or it's not something that requires a case in that particular switch.
> ...

But which one is it? I'd like to know when I read the code.

> I really am puzzled by the idea that the compiler requiring one to put `default:` is helping them remember things.
> ...

The point of `default: break;` is that it explicitly states "I am doing nothing if it's not one of the other cases". A switch can be pretty long, so it's convenient to be able to search for the default case and be confident you won't end up in an unrelated long switch.

> To be honest, I'm OK with the requirement. I really am, I can write `default: break;` and I actually do with regularity without forgetting! But it's a hard one to explain to newcomers. It's just one of those things that I explain with "D makes you do this, get over it". I can't really explain that it's helpful with a straight face.

There are multiple common ways to deal with the default:

- You actually meant to use `final switch`.
- Do some explicit action
- assert(0);
- enforce(0,"TODO: handle case")
- Do nothing

I seldomly want to do nothing. Why should that be the implicit default?