Using unions for a result

[Visual-Dawg]

When an union of Error and/or Ok is provided to a function like R.isOk, it will not accept the input, even though the code will run.

This makes it a lot harder to return different errors within a pipe. Accepting different Error and Ok types which then get narrowed down, would be a lot nicer.

Example:

// Simplified code example
import { R } from "@mobily/ts-belt"

function fn(a: number) {
    if (Number.isNaN(a)) return R.Error("Number is NaN")

    return a > 10
        ? R.Ok("Is bigger than 10")
        : R.Error({ value: a, message: "Number too small" })
}

R.isOk(fn(10)) // => Errors

[Visual-Dawg]

It looks like that there is no perfect solution - but changing the signature of R.isOk to

declare function isOk<A, unknown >(result: Result<A, unknown>): result is Ok<A>;

Makes it a lot more compatible. Same goes for R.isError

[JUSTIVE]

I think the fn type should define its result type. In your example, the fn's type signature is function fn(a: number): R.Error<string> | R.Ok<string> | R.Error<{ value: number; message: string; }>, in which the Error type is separated. that's not even possible with rescript code.

let fn = x => {
  switch x {
  | x if Float.isNaN(x) => Error("Number is NaN")
  | x if x > 10. => Ok(x)
  | _ => Error({value: x, message: "Number too small"}) 
  // ^ where error occurs, because the type system inferences 
  // fn's return type as result<float, string> from the first match clause.
  }
}

in rescript, we can fix by describing the custom error type, in this case, a variant represents two cases of the errors.

type myError = JustError(string) | ErrorWithMessage({value: float, message: string})

let fn = (x: float): result<float, myError> => {
  switch x {
  | x if Float.isNaN(x) => Error(JustError("Number is NaN"))
  | x if x > 10. => Ok(x)
  | _ => Error(ErrorWithMessage({value: x, message: "Number too small"}))
  }
}

Maybe some black magic of type-level programming in typescript would handle this, but I think It'll hurt the signatures of functions in the Result module's readability(yes, this change should be applied to all the functions in result module, not just isOk and isError, since the input value, in this case the return type of the fn function is not sanitized).

So I think, in this case you can just write your own error type, not changing signatures of the functions.

type MyError = string | {
    value:number,
    message:string
}

function fn(a: number):R.Result<number,MyError> {
    if (!G.isNumber(a)) return R.Error("Number is NaN")

    return a > 10
        ? R.Ok(a)
        : R.Error({ value: a, message: "Number too small" })
}

const x = R.isOk(fn(10)) // => no more errors

[JUSTIVE]

I'll post a type that meets your request later here, let me know what you think!

[Visual-Dawg]

@JUSTIVE Hey, thank you for the detailed response! :)

For errors this could work, however, within a pipe Ok types are often implicitly defined, and being able to pass to R.isOk a union of R.Ok<string> | R.Ok<something lese> | R.Error to filter out the errors, does seem like a good use case.

But, if this is a ReScript limitation, there also doesnt seem to be a good solution to this ,except manually changing the generated Typescript code, which is not optimal

[JUSTIVE]

rescript, which is the basis of ts-belt, does not work like this because it uses a stricter type system than typescript. Since typescript is much more flexible than rescript, there seems to be a way if you want to try it. I'm currently working on a trick using hotscript, and I'd like to share it with you as soon as it's completed.

[Visual-Dawg]

Sounds cool, thank you :)

[JUSTIVE]

just finished making a simple proof-of-concept. here's link

[JUSTIVE]

While it may enhance developer experience(at least at a type level), I think It's a hacky way to achieve with the current state of typescript's type system. I didn't consider compiler performance and readability of the implementation. It's a very impractical case I guess.

we can easily remove these nightmare types by adding a type to your function.

[Visual-Dawg]

Didnt see your message, sorry! This looks so cool, but I do not understand it. It is realy Typescript wizardry, quite impressive :D And yes, the resulting type might be too much, but still, cool stuff :D

[JUSTIVE]

guess it's ok to close this issue?

[Visual-Dawg]

Yep :)