Warn for strict where bindings attached to clause with multiple GRHSs
-- NB: Do not be tempted to make the next (Var fun, args, tick) -- equation into an 'otherwise' clause for this equation -- The former has a bang-pattern to occ-anal the args, and -- we don't want to occ-anal them twice in the runRW# case! -- This caused #18296
We basically have the situation (after possibly merging a multi-clause defn into a single clause with multiple GRHSs)
f x y | ... = ... | ... = ... ... -- 1000 lines later | otherwise = ... lazy in expensive ... where !expensive = ...
Which makes the first two GRHS force
expensive even if they don't need it!
where bindings in this setting seems like bad practice and we should discourage it.
For another data point: In Lean 4 (which has strict evalution semantics), they plan to introduce
where bindings, but probably only for arity > 0 after I had this discussion with a co-worker.