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

Move TypeScript generics as deeply into function signatures as possible #372

Closed
Avaq opened this issue Sep 17, 2019 · 0 comments · Fixed by #374
Closed

Move TypeScript generics as deeply into function signatures as possible #372

Avaq opened this issue Sep 17, 2019 · 0 comments · Fixed by #374

Comments

@Avaq
Copy link
Member

Avaq commented Sep 17, 2019

What about making fold

export function coalesce <LA, RB>(lmapper: (left: LA) => RB): <RA>(rmapper: (right: RA) => RB) => <LB>(source: FutureInstance<LA, RA>) => FutureInstance<never, RB>

I suppose that should be because some throw, like in the case of

See #331. In order to call promise on a Future, the rejection branch must now be compatible with type Error, and thrown exceptions are now merged with the rejection branch, instead of being rethrown.

but not sure if that's a problem of fold

Also in general add the generic <T> as late as possible has proven to be more effective, with the fluture@12.0.0-beta.3 i needed to type way more functions, specially fold and bimap. when i change bimap to

export function bimap<LA, LB>(lmapper: (reason: LA) => LB): <RA, RB>(rmapper: (value: RA) => RB) => (source: FutureInstance<LA, RA>) => FutureInstance<LB, RB>

ts infers way better the bimap type.

Originally posted by @edgarjrg in #370 (comment)

@Avaq Avaq mentioned this issue Sep 17, 2019
Avaq added a commit that referenced this issue Sep 25, 2019
- Revert #230 and reintroduce the usage of the 'never' type
- Relax the signature of chain and chainRej to allow TypeScript to
  derive types when merging a Future of a never with a Future of a
  real type. Closes #337 and closes #370.
- Move generic types closer to where they are used in the function
  signature. Closes #372 and closes #373 through supersession.

Co-authored-by: Edgar Rodriguez <edgarj.rodriguezg@gmail.com>
@Avaq Avaq closed this as completed in #374 Sep 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant