[](otherwise){ return g(); } // This function will be invoked if x's
// value is of any type except B
);
```
It is of course possible to have several specific match clauses before the otherwise-clause, but make sure to always put `otherwise` last—or else any clause appearing below it will never actually be executed. Simply put, matching is done in the order the expressions appear.

The true usefulness of `sum_type` isn't so much the case where you use it directly. It's when you use it to quickly and cleanly create new data types. For example, did you know both `ftl::maybe` and `ftl::either` are really just simple type aliases of `sum_type`? It's true, `maybe` is defined simply as:
```cpp
template
using maybe = sum_type;
```
That takes care of the vast majority of the logic required for `maybe`, though there is a number of convenience functions and definitions in addition.

### Applying Applicatives
Adding a bit of the Applicative concept to the mix, we can do some quite concise calculations. Now, if we are given:
```cpp
int algorithm(int, int, int);
ftl::maybe maybeGetAValue();
ftl::maybe maybeGetAnother();
ftl::maybe maybeGetAThird();
```
where `ftl::maybe` is a type similar to e.g. `boost::optional`, provided by FTL (mostly to make sure there are no external dependencies save the standard library).

Then we can compute:
```cpp
/* ftl::operator% is short for ftl::fmap, basically the classic "map" function
* of functional programming.
* Similarly, ftl::operator* is short for ftl::aapply, the work horse function of
* applicative programming style. It basically applies a function (the left hand
* side) to one argument at a time (the right hand side).
*/
using ftl::operator%;
using ftl::operator*;
auto result =
ftl::curry(algorithm) % maybeGetAValue() * maybeGetAnother() * maybeGetAThird();
```
which would compute the result of algorithm, but only if every one of the `maybe` functions returned a value.

In other words, without Functor's `fmap` and Applicative's `aapply`, it would have looked something like:
```cpp
ftl::maybe result;
auto x = maybeGetAValue(), y = maybeGetAnother(), z = maybeGetAThird();
if(x.is() && y.is() && z.is()) {
result = ftl::value(algorithm(ftl::get(x), ftl::get(y), ftl::get(z)));
}
```
If `algorithm` had happened to be wrapped in an `ftl::function`, or else be one of the built-in, curried-by-default function objects of FTL, then the `curry` call could have been elided for even cleaner code.

Exactly what operation is done by `apply` varies from type to type. For example, with containers, it generally implies combining their elements in every possible combination. Thus
```cpp
curry(std::plus) % std::list{1,2} * std::list{5,10};
```
can be read as "for each element in `{1,2}`, combine it using `std::plus` with each element in `{5,10}`", resulting in the list `{6, 11, 7, 12}`. Of course, what happens on a more technical level is that `std::plus` is partially applied to each element in the first list, resulting in a list of unary functions, that in turn gets applied to each element in the second list.

A much less technical way of thinking—to gain some intuition for how applicative expressions behave—could be that `operator%` is an alias for function application, and `operator*` separates parameters. Except the parameters happen to be wrapped in some "context" or "container".

This type of function application scales to arbitrary arity.

### Transformers
No, not as in Optimus Prime! As in a monad transformer: a type transformer that takes one monad as parameter and "magically" adds functionality to it in the form of one of many other monads. For example, let's say you want to add the functionality of the `maybe` monad to the list monad. You'd have to create a new type that combines the powers, then write all of those crazy monad instances and whatnot, right? Wrong!

```cpp
template
using listM = ftl::maybeT>;
```
Bam! All the powers of lists and `maybe`s in one! What exactly does that mean though? Well, let's see if we can get an intuition for it.

```cpp
// With the inplace tag, we can call list's constructor directly
listM ms{ftl::inplace_tag(), ftl::value(1), ftl::maybe{}, ftl::value(2)};

// Kind of useless, but demonstrates what's going on
for(auto m : *ms) {
m.matchE(
[](int x){ std::cout << x << ", "; },
[](ftl::Nothing){ std::cout << "nothing, "; }
);
}
std::cout << std::endl;
```
If run, the above would produce:
```
1, nothing, 2,
```
So, pretty much a list of `maybe`s then, what's the point? The point is, the new type `listM` is a monad, in pretty much the same way as `std::list` is, _except_ we can apply, bind, and map functions that work with `T`s. That is, given the above list, `ms`, we can do:

```cpp
auto ns = [](int x){ return x-1; } % ms;

// Let's say this invokes the same print loop as before
print(ns);
```
Same deal, but if `ms` was a regular, untransformed list of `maybe`:
```cpp
auto ns = [](maybe x){
return x.match(
[](int x){ return ftl::value(x-1); },
[](otherwise){ return ftl::nothing(); }
);
} % ms;

print(ns);
```
Output (in both cases):
```
0, nothing, 1,
```
So, basically, this saves us the trouble of having to check for nothingness in the elements of `ns` (coincidentally—or not—exactly what the maybe monad does: allow us to elide lots of ifs or pattern matches).

Right, this is kinda neat, but not really all that exciting yet. The excitement comes when we stop to think a bit before we just arbitrarily throw together a couple of monads. For instance, check out the magic of the `either`-transformer on top of the `function` monad in the parser generator tutorial [part 2](docs/Parsec-II.md).

### Yet More Concepts
In addition to the above concepts, FTL contains several more of the classic Haskell type classes: Monoids, Foldables, Zippables, and Orderables. These all express nice and abstracted interfaces that apply to many types, both built-in, standard library ones, and user defined ones (assuming one adds a concept instance). For instance, the code below uses the fact that an ordering is a Monoid to sort a vector of `MyType` by first one of its properties, then another.
```cpp
using namespace ftl;
std::sort(vec.begin(), vec.end(),
asc(comparing(&MyType::someProperty) ^ comparing(&MyType::anotherProperty))
);
```
The equivalent version without FTL might look a bit like this:
```cpp
std::sort(vec.begin(), vec.end(), [](const MyType& lhs, const MyType& rhs){
return lhs.someProperty() == rhs.someProperty()
? lhs.anotherProperty() < rhs.anotherProperty()
: lhs.someProperty() < rhs.someProperty();
});
```
Personally, I find the former a lot cleaner and easier to read. The sort order is explicitly stated (`asc`), and then it just straight up says that we sort by comparing first `someProperty` and then `anotherProperty`. Fewer chances of subtle typos, less chance of screwing up the comparisons, much easier to extend, what's not to like?