There's certainly situations where this pattern creates some tricky ambiguity, but more often than not Result is quite an ergonomic pattern to work with.
In case it's useful for anyone, here is a simple plug-in-play TypeScript version:
```
type Ok<T = void> = T extends undefined ? { ok: true; } : { ok: true; val: T; };
type Err<E extends ResultError = ResultError> = { ok: false; err: E; };
type Result<T = void, E = ResultError> = { ok: true; val: T; } | { ok: false; err: E | ResultError; };
class ResultError extends Error { override name = "ResultError" as const; context?: unknown; constructor (message: string, context?: unknown) { super(message); this.context = context; } }
const ok = <T = void>(val?: T): Ok<T> => ({ ok: true, val: val, } as Ok<T>);
const err = (errType: string, context: unknown = {}): Err<ResultError> => ({ err: new ResultError(errType, context), ok: false, });
```
```
const actionTaker = await op().then(ok).catch(err);
if (result.ok) // handle error
else // use result
```
I will be forever grateful to the developer first introduced to this pattern!
This doesn't pass the smell test. Whenever I've seen the Result or Either type, the definition looked different than what you wrote here. I doubt this composes nicely, with Folktale and fp-ts I can be certain.
100% if you want composability go with a battle tested solution! That code really just demos how simple working the Result pattern can be.