Generic Result Types

Beginner used a result union for one parser. A generic Result<T> reuses that relationship across operations: success contains T, failure contains a structured Issue. The boolean literal ok is the discriminant, just as kind was in the earlier course.

{ ok:true; value:T } | { ok:false; issue:Issue } does not permit a success without data or a failure without details. Always narrow before reading variant-specific fields. A generic result is still an ordinary runtime object; its type does not make the operation succeed.

Use one failure representation consistently across a small boundary. Our Issue has path and message so callers can identify a malformed row or field without parsing a prose sentence. Returning an Issue is useful for expected bad data. Unexpected programming defects should not automatically be disguised as valid error results.

The example maps a successful value while retaining the same failure branch. No assertion is necessary because the branch gives the checker enough evidence.

Predict, run, and explain

Write the output and trace the important state changes before checking it. Then run the program. Use Check types first; execution is allowed only when the real compiler accepts the source.

type Issue = {
  path: string;

  message: string;
};

type Result<T> =
  | {
      ok: true;

      value: T;
    }
  | {
      ok: false;

      issue: Issue;
    };

function mapResult<A, B>(
  result: Result<A>,
  transform: (value: A) => B
): Result<B> {
  if (!result.ok) {
    // Preserve the failure without calling transform.
    return result;
  }

  return { ok: true, value: transform(result.value) };
}

const result = mapResult<number, string>(
  { ok: true, value: 25 },
  value => `${value} min`
);

console.log(result.ok ? result.value : result.issue.message);

25 min

Read the compiler error

The result is not known to be the success variant here.

type Result<T> =
  | {
      ok: true;

      value: T;
    }
  | {
      ok: false;

      message: string;
    };

function read(result: Result<number>): number {
  return result.value;
}

Map success without inventing success from failure

A Result<T> describes a known success value type while preserving an explicit expected-failure branch. A transformation should apply its callback only to success and carry failure through unchanged. Otherwise it can run code on data that was never produced.

The compiler enforces branch access and the declared output relationship. It cannot prove that the callback runs the intended number of times or that error identity was preserved. Keep those as observable runtime checks.

type Result<T> =
  | {
      ok: true;

      value: T;
    }
  | {
      ok: false;

      message: string;
    };

function map<T, U>(result: Result<T>, fn: (value: T) => U): Result<U> {
  return result.ok ? { ok: true, value: fn(result.value) } : result;
}

const result = map({ ok: true, value: 0 }, value => value + 1);

console.log(result.ok ? result.value : result.message);

1

Zero enters the success mapper because ok carries the outcome. A truthy-value condition would lose a valid success.

type Result<T> =
  | {
      ok: true;

      value: T;
    }
  | {
      ok: false;

      message: string;
    };

function map<T, U>(result: Result<T>, fn: (value: T) => U): Result<U> {
  return result.ok ? { ok: true, value: fn(result.value) } : result;
}

let calls = 0;
const failure: Result<number> = { ok: false, message: "bad" };
const result = map(failure, value => {
  calls++;
  return String(value);
});

console.log(calls, result === failure);

0 true

No transformation ran and the original failure object survived. The output can use another success type without manufacturing a value on the failure path.

Try the rule on new inputs

Test success with zero, a normal success and failure. Make the mapper throw and decide whether that programming error should propagate or become a separate expected failure; document the policy before changing it.

Your turn

// Narrow with result.ok before reading value or issue.

type Issue = {
  path: string;

  message: string;
};

type Result<T> =
  | {
      ok: true;

      value: T;
    }
  | {
      ok: false;

      issue: Issue;
    };

function describe(result: Result<number>): string {
  if (result.ok) {
    return String(result.value);
  }

  return `${result.issue.path}: ${result.issue.message}`;
}

console.log(describe({ ok: true, value: 0 }));
console.log(
  describe({ ok: false, issue: { path: "pages", message: "Invalid count" } })
);

0
pages: Invalid count

Change it and test it

Try reading value without narrowing and inspect the error. Create an invalid success missing value and confirm checking fails. Explain why a well-typed decoder can still return a dishonest result unless its runtime checks are tested.