What is the best way to achieve Rust question mark operator-like behavior

[snaumov]

Thank you for the great library!
I was wondering what would be the best way to achieve question mark operator behaviour using the true-myth existing API?

For now I settled on

cons result: Result<T, E> = fallible_method();
if (result.isErr()) { return result };

[chriskrycho]

Great question! There isn’t really any much better translation than that, because JS doesn’t have native pattern matching. Strictly speaking, you want to do roughly this so that you can get a new error of the correct type, rather than doing an unsafe cast (TS playground):

import { Result } from 'true-myth/result';

function demoEarlyReturn(result: Result<string, Error>): Result<number, Error> {
    if (result.isErr()) {
        return Result.err(result.error);
    }

    const { value } = result;
    return Result.ok(value.length);
}

This isn’t great in performance-sensitive code, given the extra allocation… but the unfortunate reality is that our Maybe and Result aren’t great in performance-sensitive code anyway because they allocate a lot.

---

One thing this has me thinking on is the value of some method that would allow you to take an Err<T, E> and turn it into an Err<U, E>, or an Ok<T, E> into Ok<T, F>, with the syntax you showed but without the extra unwrapping and rewrapping. 🤔 Something to think on!

[chriskrycho]

No, we don't have anything that way. It's an interesting idea, but synthetic benchmarks are often uninformative for things like this (even actively misleading), and real life and real world benchmarks for something like this are really hard to get!

Here, it is also complicated by the fact that if you are using something like optional chaining and nullish coalescing, you may be dealing with the compiled output, which could have its own overhead. A chain of optional chaining operators compiles to a pretty large amount of output with a high number of branches, which also has significant performance costs – including in how much has to go across the wire! But if you're only targeting browsers which support it natively, that should be that much more efficient.

In general, if you are not worried about using other objects, allocations, branching, etc., I wouldn't be worried about using True Myth. If you are in the kind of performance-sensitive code where you are already reaching for fine-grained optimization techniques (e.g. pre-allocated arrays that you index into instead of object allocations) then this probably isn't a great fit. For the vast majority of JavaScript code out there, this should be totally fine.

[snaumov]

thank you, makes perfects sense!

[Nick-Mazuk]

You may be able to avoid the extra allocation in the example since the result is already a result type:

if (result.isErr()) {
    return result;
}

[chriskrycho]

@Nick-Mazuk not without a cast! If you try that, you'll see that you actually end up having to write something like this:

if (result.isErr) {
  return result as unknown as Result<number, Error>;
}

This is because Result<string, Error> is (correctly!) not assignable to Result<number, Error>. It'd be interesting to implement a no-op .safeCast() call or some such. (I am mucking around a little bit with that now!)

[chriskrycho]

I ended up implementing exactly that: as of True Myth 7.0, just released, .cast() is available specifically on Ok and Err (i.e. when you have narrowed using .isOk or similar) types, where it is guaranteed to be safe.