Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make typings for algebras more strict #458

Open
Avaq opened this issue Jan 8, 2021 · 0 comments
Open

Make typings for algebras more strict #458

Avaq opened this issue Jan 8, 2021 · 0 comments

Comments

@Avaq
Copy link
Member

Avaq commented Jan 8, 2021

This issue assumes the approach in #438 was taken, and proposes a possible follow-up.

Currently, it's allowed to combine Futures with differing rejection types, for example in the following overload for alt, the rejection type is known, but not enforced in the second argument:

Fluture/index.d.ts

Lines 94 to 99 in 06bc7c9

<L>(second: Rejected<L>): {
(first: Never): Never
(first: Rejected<any>): Rejected<L>
<R>(first: Resolved<R>): Resolved<R>
<R>(first: Uncertain<any, R>): Uncertain<L, R>
}

The same goes for the piped version of this type:

<F extends AnyFuture, S extends AnyFuture>(second: F extends Rejected<unknown> ? S : never): (first: F) => S

Both could be made to tell the user they are doing something naughty when the user attempts to provide a second Future with a differing rejection type:

<L>(second: Rejected<L>): {
  (first: Never): Never
  (first: Rejected<L>): Rejected<L> // L instead of any
  <R>(first: Resolved<R>): Resolved<R>
  <R>(first: Uncertain<L, R>): Uncertain<L, R> // L instead of any
}
// infer L from F and constrain S
<F extends AnyFuture, S extends AnyFuture>(second: F extends Rejected<infer L> ? S extends Uncertain<L, unknown> ? S : never : never): (first: F) => S

This same principle applies to other algebras that wouldn't normally allow for changes in the rejection branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant