F# – Idiomatic Way to Express Sequence of If Statements with Overlapping Conditions

Let's say I got code like this:

if(conditionA)
    do something
if(conditionA && conditionB)
    do something more

Obviously, I could nest the ifs (although when there are more complicated conditions this is not readable for me) like below:

if(conditionA)
    do something
    if(conditionB)
        do something more

How can I write similar code in f# idiomatically. I assume if statement isn't considered idiomatic in functional programming (am I wrong?)

I could write two subsequent match expressions or nested match expression to mimic above code but doing so seems pretty ugly to me.

Best Answer

There's nothing wrong with using if-then-else in F#. It's as idiomatic as things can get. Most people do highlight match expressions when talking about F#, so it may seem that ifs are discouraged, but that's not really the right way to think of things.

That's true that match expressions are powerful. It doesn't take much to benefit from using them instead of ifs when:

you can use deconstruction in the patterns,
or you want to match a tuple of values,
or you have more cases than a binary true/false and want to handle them without building if-else towers.

That said using the construct below should be called out in a code review (and rightly so - this should have been an if):

match cond with
| true -> ...
| false -> ...

It's roughly on the same level of code smelliness as the dreaded construction you might sometimes see in bad c-style lang code:

/// this is bad, don't do this at home (just return cond).
if (cond) {
    return true;
} else {
    return false;
}

I don't see a problem in your second snippet with nested ifs. That said, there might be better solutions, but it's hard to suggest one when talking about do somethings and conditionBs.

Related Solutions

Way to created nested computation expressions

Have you tried any of the bang (!) keywords? You might be able to do it like so:

let specs =
    describe "Some feature" {
        do! describe "in some context" {
            do! it "has some behavior" (fun () -> 
                // Test code goes here
            )
        }
        do! describe "in some other context" {
            do! it "has some behavior" (fun () -> 
                // Test code goes here
            )
        }
    }

assuming your it returns something in the describe workflow.

(The above might be improper F# as I've been away from it for a while, but you should be able to do something like it.)

C# – In what way are union types better for correctness than a common interface

There is no benefit from from having addItemToCart rather than ICart.AddItem. They are essentially identical. Both of those necessarily have a runtime check, because you want to be able to have a variable with any kind of Cart in it, and you won't know at compile time which one will get passed into the function.

Where the benefit comes is when you first implement addItemToCart, or later when you add another operation at the same level of abstraction, say oneClickAddAndPay. The union type will give you a compile error if you try to Add an item to a PaidFor cart, or if you completely forget to account for PaidFor carts at all. The ICart interface can't catch that kind of programming error at compile time.

In other words, the union type can't move all kinds of errors to compile time, but it does move some. If you don't end up adding a lot of functions like oneClickAddAndPay that reuse the existing Add functionality, it won't buy you much.