How to Represent Functional Boolean

[tiksn]

.NET Boolean type usually makes if else pair all over the code.

Functional Boolean should be more like Either type. Ideally represented as Either<Unit, Unit>.

However, my issues with Either type are the following:

1. Either<Unit, Unit> verbose, ideally it should not be generic type
2. It is not communicating clearly that EitherLeft is false and EitherRight is true

There is a library that solves this, here are some examples

TrueOrFalse IsWeekend()
{
    var dow = DateTimeOffset.Now.DayOfWeek;

    if (dow == DayOfWeek.Saturday || dow == DayOfWeek.Sunday)
    {
        return new TrueOrFalse.True();
    }

    return new TrueOrFalse.False();
}

YesNoOrMaybe CanPurchaseAlcohol(int age)
{
    if (age < 16)
    {
        return new YesNoOrMaybe.No();
    }

    if (age >= 21)
    {
        return new YesNoOrMaybe.Yes();
    }

    return new YesNoOrMaybe.Maybe();
}

However, I have issues with this one as well

1. I do not want to have 2 similar libraries in my projects solving similar problems.
2. new TrueOrFalse.True() seems to me as wasteful, allocating objects every time which in essence Unit.Default. I would Prefer something like TrueOrFalse.True.Default
3. language-ext mainly uses structs, where OneOf uses classes. That is why I would like to stick with language-ext

I was thinking to create a specialized type, let's call it Binate (still working on the name) which will be similar to Either<Negative, Positive>, where Positive and Negative are specialized Unit types.

However, that will mean copying and renaming types from language-ext

---

My question is, how have you solved this problem in your projects? Which approach would you recommend?

[MrYossu]

However, my issues with Either type are the following:

1. Either<Unit, Unit> verbose, ideally it should not be generic type
2. It is not communicating clearly that EitherLeft is false and EitherRight is true

1. Why not just create an alias for Either<Unit, Unit>? That's like creating a Validation<T> type that is really no more than Either<Error, T> where Error is some known type that contains the error info. You're just taking this one step further and specifying both types.
2. In what way does Either communicate that Left is false/error/whatever and Right is true/good/whatever? It doesn't, it's just convention that we understand it. so, your new type could use Match (as it's basically an Either) and convention would dictate which branch was true and which was false.

I'm no expert, so please feel free to take any other advice that comes along, but I would start that way and see where it got me.

[timmi-on-rails]

What is the actual problem to solve?
Couldn't you just use the terneray operator instead of if else for a more functional style?
I guess the problem is the imperative nature of if else. There is nothing wrong with a C# bool, is there?

I would be confused using Either instead of a bool, because Either has a bias on one of the two possible boolean values being an error.

[tiksn]

What is the actual problem to solve?

The first use case that I am thinking of using is feature flags. They are not just Booleans. They really split your application into two.

Either (or a similar type) will force the user to provide action in both cases, when the flag is on and when the flag is off.

Another use case is having dynamic feature flags that actual value will be requested (from API) whenever asked (by code). In this case, we can also combine (use logical operators) like var allEnabled = canViewStatistics && canEditRecords. allEnabled.MatchAsync(positive => doSomethingAsync(), negative => doAnotherThingAsync())

Couldn't you just use the ternary operator instead of if else for a more functional style?
I guess the problem is the imperative nature of if else. There is nothing wrong with a C# bool, is there?

My goal is not to replace bool entirely. Majority of cases, still bool will be used.

[louthy]

It's a very strange request. Monads are for chaining operations: they yield a value when they're able to continue. You could consider this to be like true (but true + a value). If the monad can yield a value it's a truth, if not it's a falsity (false and no value). That's OK, but in your example the only value that will ever be yielded is Unit (or a version of). What's the point in that? It has no value outside of chaining operations together. It will never yield a usable value from within the monad (other than true or false).

If you just want the chaining behaviour of monads use && with bool, it does exactly what you're asking for. It stops on false and continues on true. If all are true the proposition has been proven.

If you desperately want to reproduct the existing behaviour of bool, but slower, and with your own types. Then you can read the wiki on discriminated-unions and the LanguageExt.CodeGen library that allows you to generate them. I would advise against the OneOf approach (search the issues, I've discussed it before).

I answered a question a few years back on 'functional if' on Stack-Overflow, which maybe is closer to what you need. Note though, the Decision monad carries a value, not just a boolean. It also works more like a reader monad, so that you can build reusable decision expressions. Those expressions can then invoked (they're delegates) that result in binary decisions.

[tiksn]

Thanks for the detailed answer and Stack Overflow link. Decision sounds like the type I need.