The biggest pain point is having to enable RebindableSyntax, which is quite heavy. Something like QualifiedIf might be nice, although it would be a lot more niche than QualifiedDo.
Personally I prefer the former, and in fact, given that case is so lightweight and \case is even more lightweight, I’d be willing to use a language that doesn’t have if at all! I don’t strongly see the point of if cond then e1 else e2 when case cond of True -> e1; False -> e2 is available.
I guess it’s self explanatory. Of course it allows the use of if and so on. The way you named the type, ShouldShow, there is no confusion what True and False represent and you are about to reimplement Bool, anyway.
Second: don’t use if
This is how I actually do stuff:
data ShowHide
= Show
| Hide
More verbose and explicit alternative:
data Visibility
= VisibilityShow
| VisibilityHide
Of course, both of them allow to add a third value at any time, e.g. for a blocking and a collapsing version of a hidden state.
And I don’t usually see a problem with the resulting
case visibility of
VisibilityShow -> ...
VisibilityHide -> ...
My personal choice
My dirty secret: I even use case on bool types because if results in line breaks and white space that interrupt the flow (my subjective view). case is just so much clearer and more flexible at the same time.
Because of my dirty secret your initial problem/challenge turns out to be none. Avoid boolean blindness, prefer case over if strictly, have elegant and flexible code.