Skip to content

Make typings for algebras more strict #458

@Avaq

Description

@Avaq

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions