TaggedError requirement

[rrmesquita]

Problem

— I would open this as a discussion, but this repo has disabled discussions tab.

First, thank you so much for the effort you've put in this library. It looks great at a glance!

I wonder if the usage of TaggedError is a hard requirement for this lib to work well, or if it can be used with normal errors too. I ask this because we already use another solution for modelling domain errors, so depending on this library at this level is almost an adoption barrier. Nevethrow allows anything to be used in error paths, so I assume the role of TaggedError is to filter which errors are modeled and which are unexpected. To be clear, I'm just asking the design decision behind TaggedError.

Proposed solution

I think a better interoperability with the user's existing errors could greatly increase this library's adoption.

Alternatives considered

No response

Scope check

• I've read CLAUDE.md and this doesn't duplicate an existing concept or a deliberately-excluded one (generator do-notation, error accumulation, aliases, an Option type).

[btravers]

Thanks for the kind words, and for asking — this was a fair thing to be unsure about.

Confirming: TaggedError is not a requirement. Result<T, E> is generic in E and unconstrained — there is no E extends { _tag: string } anywhere in core, and P.tag("X") is only sugar for the object pattern { _tag: "X" }, one pattern among several. Your existing error types work as-is: match on a kind / code field with an object pattern, on an untagged class with P.instanceOf, on anything else with P.when. The only real requirement is that E is a union TypeScript can discriminate, since exhaustiveness is Exclude over it — the same thing a switch needs.

And the modelled/unexpected split you were reaching for is not done by the error’s shape at all: it is qualify at the boundary. What you return becomes E; what you hand to the injected defect helper leaves the modelled type entirely.

The docs led you to think otherwise, though, which is on us — so #236 fixes the framing and adds a runnable example (examples/existing-errors) that uses no TaggedError anywhere: your own kind-discriminated classes, a plain code union with no classes at all, and untagged third-party classes qualified at a boundary. It typechecks and its specs run in CI, so the claim can no longer quietly rot.

👉 #236

[rrmesquita]

Wow, I'm positively surprised with that information, and amazed by how quickly you addressed my comment. I'll play with this library and hopefully make the switch from neverthrow into it, because the defect channel is extremely promising. Again, thank you and hope you get many stars!