> This is not about the coding police coming to get you but preventing you from shooting yourself into your feet when you extend the enumeration.

This.

And not necessarily yourself, but whomever maintains the software after you.

Of course this doesn't prevent someone from adding a "default" label in some future iteration.

I think you guys are missing something in my perplexed state at this construct. I'm not saying it out of lack of experience or because I disbelieve in the "going out of my way to make things more maintainable though verbosity" aspect. It's just that many times in practice I have rarely seen an honest switch statement that really needs case labels for all possible values. Much more common in my experience, 1 or more cases are no-ops. I think it's pointless to list out the no-ops, but I've seen people advocate just that.

There are exceptions to this "some cases are no-ops" thing. But I think it's the minority of switches I've seen.

From that perspective it does seem like the coding police angle. It's reminiscent of certain things in Java, like making a bunch of implicit conversions into errors, or C#, which forbids implicit fall-through on a switch. Those too are for safety and maintainability. They also make a lot of constructs more ugly. My question is: is it worth it? In this case (unintended pun) I don't think so.

Really? I've literally never written (or at least I don't ever remember writing) a case statement without either specifying every possible value or adding a meaningful default case.