Complex boolean logic is quite common in F#, e.g. see examples below. It is really hard to debug.
I propose we add debug points on left and right of a && b and a || b so you can step through this logic and hit breakpoints.
C# doesn't allow breaking in boolean logic or any expression. However
- F# already steps through any
match and if ... then .. else expressions so adding this seems natural enough.
- I believe complex boolean logic is more common in F# than C# because of the expression-oriented nature of the language
A possible downside is that of "too much stepping" so it takes too long to step through a function. However I've been frustrated by the lack of debugging for boolean logic enough that I think we should prefer the addditional debug points.
Examples
let isRecdOrStructTyconRefAssumedImmutable (g: TcGlobals) (tcref: TyconRef) =
tcref.CanDeref &&
not (isRecdOrUnionOrStructTyconRefDefinitelyMutable tcref) ||
tyconRefEq g tcref g.decimal_tcr ||
tyconRefEq g tcref g.date_tcr
or

Complex boolean logic is quite common in F#, e.g. see examples below. It is really hard to debug.
I propose we add debug points on left and right of
a && banda || bso you can step through this logic and hit breakpoints.C# doesn't allow breaking in boolean logic or any expression. However
matchandif ... then .. elseexpressions so adding this seems natural enough.A possible downside is that of "too much stepping" so it takes too long to step through a function. However I've been frustrated by the lack of debugging for boolean logic enough that I think we should prefer the addditional debug points.
Examples
or