lue-bird/elm-and-or - version: 1.0.0

for more information visit the package's GitHub page

Package contains the following modules:

both or only one of them

AndOr

The basic types of this package look like this:

type AndOr first second
    = Both ( first, second )
    | Only (Or first second)

type Or first second
    = First first
    | Second second

Both types can be quite useful! ...But first

❌ misuse-cases

AndOr and Or are prone to misuse, just like Maybe, tuple, Bool etc.

When there is a representation of your data that's more descriptive, use that instead!

Example: Modeling the result of an operation that can fail, succeed or succeed with warnings

type alias Fallible a =
    AndOr a Error

This is problematic from multiple standpoints: - Why should error and warning types be required to be the same? - Why not have a unified case for success: elm type alias Fallible a = Or { result : a, warnings : List RecoverableError } UnrecoverableError - Who tells you that "first" means "success" and "second" means "error"? (or the other way round?) - Why not use descriptive names: elm type Fallible a = Success { result : a, errors : List RecoverableError } | UnrecoverableError UnrecoverableError

✔️ use-cases

AndOr and Or are useful for generic operations where no descriptive names exist – similar to how tuples are used for partition results because there is no information on what each side means.

prior art – AndOr

All of them don't separate out the "only one of both" case.

prior art – Or

All of them use Left and Right as variant names whereas Or's First and Second are consistent with elm's tuple part names.

suggestions?

The API is pretty slim, only covering the needs I could think of. If you have an idea for a useful helper → contribute