Skip to content

Commit

Permalink
Bug Fix: upstream inference bug using createOptionFromNullable in a n…
Browse files Browse the repository at this point in the history
…ested runtime type, closes #67
  • Loading branch information
gcanti committed Oct 28, 2018
1 parent 648f2fa commit f715303
Showing 1 changed file with 3 additions and 3 deletions.
6 changes: 3 additions & 3 deletions src/fp-ts/createOptionFromNullable.ts
Expand Up @@ -14,10 +14,10 @@ export class OptionFromNullableType<RT extends t.Any, A = any, O = A, I = t.mixe
}
}

export const createOptionFromNullable = <RT extends t.Type<A, O>, A = t.TypeOf<RT>, O = t.OutputOf<RT>>(
type: RT,
export const createOptionFromNullable = <A, O>(
type: t.Type<A, O, t.mixed>,
name: string = `Option<${type.name}>`
): OptionFromNullableType<RT, Option<A>, O | null, t.mixed> => {
): OptionFromNullableType<typeof type, Option<A>, O | null, t.mixed> => {
const Nullable = t.union([type, t.null, t.undefined])
return new OptionFromNullableType(
name,
Expand Down

1 comment on commit f715303

@sledorze
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gcanti I'm pretty sure we were using indirect typings of A and O (basically deduced from type's type) to prevent inferring to '{}' or 'any' in some cases.

But I'm unsure what's the state of affairs with the latest changes - that's very hard to follow.
It looks like we should create some type level regressions tests for the pattern we use as it appears to regularly break with typescript updates for any moderately advanced type usage.

Those regular breaking hurts a lot, specifically with a large code base.
And sometimes they're silent, leaving no trust in the typechecker.

Note: I'm referring to that very problem here microsoft/TypeScript#27994

P.S.: for the record; the last used pattern was due to another upstream bug:

4e5238d#diff-e3f1fa5f10d7deb8394a40ef7f01d814

Please sign in to comment.