feat(core): add Result type

[AliiiBenn]

Summary

Add Result type (Ok/Err) for simple error handling in synchronous operations.

Changes

Types

• Result<T, E> - Union type of Ok | Err
• Ok - Success value: { ok: true, value: T }
• Err - Error value: { ok: false, error: E }

Constructors

ok(42)           // Ok<number> { ok: true, value: 42 }
err("error")     // Err<string> { ok: false, error: "error" }

Type Checking (2 ways)

// As functions
isOk(ok(42))    // true
isErr(err("e"))  // true

// As methods
ok(42).isOk()   // true
err("e").isErr() // true

// Type narrowing works with both
if (result.isOk()) {
  console.log(result.value)  // TypeScript knows it's Ok<T>
}

Transformations

map(ok(21), x => x * 2)           // Ok<42>
map(err("e"), x => x * 2)           // Err

flatMap(ok(5), x => ok(x * 2))    // Ok<10>
flatMap(ok(5), x => err("e"))      // Err
flatMap(err("e"), x => ok(x * 2))  // Err

mapErr(err("e"), e => new Error(e)) // Err<Error>

Extraction

getOrElse(ok(42), 0)               // 42
getOrElse(err("e"), 0)              // 0

getOrCompute(ok(42), () => heavy()) // 42 (lazy not called)
getOrCompute(err("e"), () => 42)    // 42

Pattern Matching

match(ok(42), v => v * 2, () => 0) // 84
match(err("e"), v => v * 2, () => 0) // 0

Conversions

toNullable(ok(42))  // 42
toNullable(err("e")) // null
toUndefined(ok(42))  // 42
toUndefined(err("e")) // undefined

Coverage

100% test coverage. 43 tests.

🤖 Generated with Claude Code

[marty-action]

The Ok<T> and Err<E> types include isOk() and isErr() methods, but the Success<T> type in success.ts does not have corresponding methods. This creates an API inconsistency between Result and Outcome types. Consider adding isOk() and isErr() methods to Success<T> for consistency.

[marty-action]

There's no tapErr function to perform side effects when the Result is an Err, while there is a tap function for Ok. Consider adding this for API symmetry with map/mapErr.

[marty-action]

Summary

This PR adds a Result type (Ok/Err) for simple error handling in synchronous operations, complementing the existing Outcome type (Success/Cause/Exception). The implementation follows the familiar Rust-inspired Result pattern.

Critical Issues

1. API Inconsistency between Result and Outcome (packages/core/src/result.ts:17-33, packages/core/src/success.ts:11-14): The Ok and Err types include isOk() and isErr() methods, but the Success type does not have corresponding methods. This creates an inconsistency - users of Result can use both isOk(result) function and result.isOk() method, but Outcome users only have the function form.

2. Missing tapErr function (packages/core/src/result.ts:156-161): There is a tap function for performing side effects on Ok values, but no corresponding tapErr for Err values. This breaks symmetry with map/mapErr.

Recommendations

1. Consider adding isOk() and isErr() methods to Success for API consistency between Result and Outcome types.

2. Add a tapErr function for symmetry

3. Update the README (packages/core/README.md) to document the new Maybe and Result types - currently it only documents Outcome, Success, Cause, and Exception.

Positive Notes

• Well-structured implementation following functional programming best practices
• Comprehensive test coverage (43 tests as mentioned)
• Good use of TypeScript features including type guards for type narrowing
• Objects are frozen for immutability (Object.freeze())
• Consistent naming and API design following Rusts Result pattern
• Exports are properly re-exported in index.ts with aliased names to avoid conflicts
• The distinction between Result (simple errors) and Outcome (rich domain errors) provides a clear choice for developers

[marty-action]

Consider adding an okUnit() function similar to someUnit() in the Maybe type for consistency. This would be useful for operations that succeed but don't return a meaningful value.