-
-
Notifications
You must be signed in to change notification settings - Fork 84
Open
Description
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:
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:
Line 91 in 06bc7c9
<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
Labels
No labels