Skip to content
This repository has been archived by the owner on Sep 14, 2023. It is now read-only.

re-thinking the result type #451

Closed
harrysolovay opened this issue Dec 1, 2022 · 0 comments · Fixed by #454
Closed

re-thinking the result type #451

harrysolovay opened this issue Dec 1, 2022 · 0 comments · Fixed by #454

Comments

@harrysolovay
Copy link
Contributor

The following boilerplate is starting to feel hefty.

if (result instanceof Error) {
  // ...
} else {
  // ...
}

While typing the result as a union avoids the need for a dedicated Result type, it complicates usage of the result. Perhaps the following would be better?

type Result<T, E extends Error> = {
  ok: T;
  error?: never;
} | {
  ok?: never;
  error: E;
}

This would allow for much simpler use of the ok value.

if (result.ok) {
  // ...
}

This would also enable the removal of intermediate nesting in cases such as entryRead, as we'd no longer need to worry about an any-typed ok resulting in the loss of error type narrowing.

Thoughts?

@harrysolovay harrysolovay added this to Capi Dec 1, 2022
@github-project-automation github-project-automation bot moved this to Properly Done in Capi Feb 8, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

1 participant