René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Improve type inference for generic curried functions","articleBody":"```ts\r\n// #-------------- This works\r\n\r\ntype Repeat = (n: number) =\u003e (s: string) =\u003e string;\r\nexport const repeat: Repeat = n =\u003e s =\u003e s.repeat(n); // Sweet! s and n are both inferred!\r\n\r\n// -------------------------#\r\n\r\n\r\n// #----- Problems begin here\r\n\r\ntype Repeat2 = (n: number) =\u003e \u003cT extends { repeat(n: number): T }\u003e(repeatable: T) =\u003e T;\r\n\r\n// Only n is inferred as number. Won't work with noImplicitAny enabled\r\nexport const repeat2Broken: Repeat2 = n =\u003e r =\u003e r.repeat(n); \r\n// Workaround is to redeclare everything from the type signature\r\nexport const repeat2Ugly: Repeat2 =\r\n    n =\u003e \u003cT extends { repeat(n: number): T }\u003e(r: T) =\u003e r.repeat(n);\r\n\r\n// -------------------------#\r\n\r\n\r\n// #----------- It gets worse\r\n\r\n// Type inference breaks for all args following the generic one, so even if you use\r\n// the workaround, the next args won't regain inference\r\ntype Repeat3 = \r\n    (n: number) \r\n    =\u003e \u003cT extends { repeat(n: number): T }\u003e(repeatable: T) \r\n    =\u003e (reverse: boolean) \r\n    =\u003e T;\r\n\r\n// Even if you explicitly provide the boilerplate for the generic arg, the boolean arg \r\n// won't be inferred. So the following won't work with noImplicitAny enabled\r\nexport const repeat3UglyAndBroken: Repeat3 =\r\n    n =\u003e \u003cT extends { repeat(n: number): T }\u003e(r: T) =\u003e b =\u003e { ... }\r\n\r\n// You have to add typing for the last arg\r\nexport const repeat3Uglier: Repeat3 =\r\n    n =\u003e \u003cT extends { repeat(n: number): T }\u003e(r: T) =\u003e (b: boolean) =\u003e { ... }\r\n\r\n// -------------------------#\r\n```\r\n\r\nI'd really appreciate better support for good inference in this kind of scenario, whether it is solved by supporting partial generic application or addition of participation of return-types in inference or whatever. \r\n\r\nJS libraries that use a functional programming paradigm often end up loosely or any-ly typed, because you find yourself fighting the type system and adding repetitive type noise all over your code to derive any safety. A couple of examples where better support for FP would be useful:\r\n\r\n - Libraries like React or Apollo make use of curried higher-order functions for solving cross-cutting concerns. In-fact, my original use case comes from React higher-order components\r\n - Popular FP libraries like Ramda become tedious to use in a `noImplicitAny` project because any generic functions passed or received from the library tend to quickly devolve into `{}` unless you repeatedly hand-hold the type system\r\n\r\nHere is my original use-case, if interested:\r\n\r\n```ts\r\nexport type GetState\u003cTState\u003e = () =\u003e TState;\r\nexport type SetState\u003cTState\u003e = (newState: TState) =\u003e void;\r\nexport type StatelessComponent\u003cTProp\u003e = (prop: TProp) =\u003e React.ReactElement\u003cTProp\u003e\r\nexport type StatefulComponent\u003cTProp, TState\u003e = \r\n    (stateAccess: { getState: GetState\u003cTState\u003e, setState: SetState\u003cTState\u003e })\r\n    =\u003e StatelessComponent\u003cTProp\u003e;\r\n\r\ntype ScrollableHOC = \r\n    (options: ScrollableOptions) \r\n    =\u003e \u003cT extends ScrollableProps\u003e(Child: ReactComponent\u003cT\u003e) \r\n    =\u003e StatefulComponent\u003cT, ScrollableState\u003e;\r\n\r\n// The introduction of the Child arg breaks type inference for getState, setState, props\r\nconst scrollable: ScrollableHOC = opts =\u003e Child =\u003e ({ getState, setState }) =\u003e props =\u003e {\r\n    // ...\r\n}\r\n```","author":{"url":"https://github.com/masaeedu","@type":"Person","name":"masaeedu"},"datePublished":"2017-04-05T01:12:47.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":25},"url":"https://github.com/15016/TypeScript/issues/15016"}