Brian reminded me in the other thread that as long as we voluntarily
stick to `->` style for all cases, we get all of this. So, from my
perspective, if we just adopt a style rule for Google Style that when
using switch in an expression context one should stick to `->`, I
might have basically what I want.
I hope that's true; that was certainly the intent of the -> convention,
which was intended to be the "safe and happy" place without undermining
what switch really is or foreclosing on the other options when needed.
Some additional comments inline.
The more I have thought about it, the more I believe that 95% of
the entire value of expression switch is that it /isn't procedural
switch/, and is easier to reason about than procedural switch
because of all things it /can't /do:
* can't miss cases
As John pointed out, some sort of help for exhaustiveness checking for
_statement_ switches would be nice too. We can't do this by default,
because it would change the meaning of existing code, but it would be
nice to be able to enlist the compiler's support on exhaustiveness.
This turns out to be harder than it looks, but I'll write some notes in
a separate thread.
* can't return
* can't break/continue a containing construct
Even if you cross the line from -> to :, you still get these guardrails
in expression switches.
