OrElse callback should be able to change Ok type

[braxtonhall]

• resolves #411
• resolves #437

Unfortunately this would be a breaking change, as anyone who explicitly annotated the types like orElse<A>(foo) will need to update their code to orElse<U, A>(foo)

[supermacro]

https://github.com/supermacro/neverthrow/issues/496

[myftija]

@supermacro Any updates on this? Would be really great to have this behavior for orElse :)

[jdisho]

+1

[changeset-bot[bot]]

🦋 Changeset detected

Latest commit: 378b3e530dd41ff6c2cb9a71e8b9c0b5feacc74e

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

| Name | Type | | ---------- | ----- | | neverthrow | Major |

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[braxtonhall]

It is possible to make this PR not a breaking change

- orElse<U, A>(f: (e: E) => Result<U, A> | ResultAsync<U, A>): ResultAsync<U | T, A>
+ orElse<A, U = T>(f: (e: E) => Result<U, A> | ResultAsync<U, A>): ResultAsync<U | T, A>

That way anyone who has already explicitly annotated the type arguments res.orElse<Foo>(..) will have the same behaviour as before.

The downside is of course that this is really awkward to use, especially as it swaps the order or the ok value type and the err value type. I would guess that would be super error prone and surprising to users.

[supermacro]

I think it's OK for this to be implemented as a breaking change.

Actions:

• please include a changeset file
• resolve merge conflicts
• update docs here and here

[braxtonhall]

I think it's OK for this to be implemented as a breaking change.

Actions:

• please include a changeset file
• resolve merge conflicts
• update docs here and here

Done! (i think)