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!