Shape: discriminated union vs single object

[dmvjs]

The current shape keeps all three fields on one object:

{ ok: false, value: undefined, error: e }

value is present on the error case — just undefined. That's a nullable. You've moved the problem, not removed it.

A discriminated union has two distinct shapes:

{ ok: true, value: v } // no error field
{ ok: false, error: e } // no value field

TypeScript narrows this automatically on ok. After if (!result.ok) return result, the compiler knows result.value is V — not V | undefined. No
assertion, no cast, no optional chaining.

The single-object shape loses that. result.value is always typed as V | undefined regardless of what you've checked.

Reference: github.com/dmvjs/proposal-try-expression

[ljharb]

I agree that, just like all other "result objects" in the language, value should be absent on an error, and error should be absent on a value.

[arthurfiorette]

TypeScript narrows this automatically on ok

Typescript is also able to narrow the type for other type shapes as well, but lets not get into that since typescript should adapt to this proposal and not the opposite.

From https://github.com/arthurfiorette/proposal-try-operator#instance-structure:

Crucially, a success result does not have an error property, and a failure result does not have a value property. This allows for reliable checks like 'error' in result.

This is followed on https://github.com/arthurfiorette/try/blob/9a43f9e986c51aa6b1e390c9df6c9a668e696ae1/lib/index.js#L13 as well.

Isn't this what you are asking for but in form of a class?

[ljharb]

Looks right to me.

[dmvjs]

Built a working prototype in V8 behind --harmony-try-expression using the two-shape design: github.com/dmvjs/v8/tree/harmony-try-expression

d8 --harmony-try-expression -e 'print(JSON.stringify(try JSON.parse("bad")))'
// {"ok":false,"error":{}}

[dmvjs]

Glad to hear it — I misread the implementation. Feel free to use the V8 prototype: github.com/dmvjs/v8/tree/harmony-try-expression

[DScheglov]

From https://github.com/arthurfiorette/proposal-try-operator#instance-structure:

Crucially, a success result does not have an error property, and a failure result does not have a value property. This allows for reliable checks like 'error' in result.

In the current implementation of try npm-package, the Result typing does not allow that, because the error and value fields are defined in both cases; that is, "error" in result does not discriminate the union in TypeScript. Making the types follow the Proposal (i.e. either value or error exists) breaks destructuring in TypeScript.

Actually, this is one of the reasons to throw on okResult.error and errorResult.value; that is, to prevent destructuring before discrimination in JavaScript as well.

Prior art in languages like Rust and Haskell does not allow destructuring before discrimination, because it is semantically incorrect. Even in C++, std::expected::value() throws for std::unexpected, and calling .error() on a successful result is undefined behavior.

Go allows destructuring before discrimination (actually it doesn't require the discrimination at all) -- but who is happy with error handling in Go?

I'm not sure whether the Proposal should consider TypeScript, but by including the following statement:

No generic error type for the proposed Result class will be added.

it already does.

[Arlen22]

Glad to hear it — I misread the implementation. Feel free to use the V8 prototype: https://github.com/dmvjs/v8/tree/harmony-try-expression

Yay, I've been waiting for this!