René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Inferring a generic should put the type variable in the inner scope when possible","articleBody":"# Suggestion\r\n\r\n## 🔍 Search Terms\r\n\r\n* generics\r\n* polymorphism\r\n* type inference\r\n\r\n## ✅ Viability Checklist\r\n\r\nMy suggestion meets these guidelines:\r\n\r\n* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code\r\n* [x] This wouldn't change the runtime behavior of existing JavaScript code\r\n* [x] This could be implemented without emitting different JS based on the types of the expressions\r\n* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)\r\n* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).\r\n\r\n## ⭐ Suggestion\r\n\r\nWhen inferring a generic type, put the type variable in the inner scope as long as it's possible to make the result as general as possible.\r\n\r\n## 📃 Motivating Example\r\n\r\nSay I have a simple composition function:\r\n\r\n```typescript\r\ndeclare const compose: \u003cA, B, C\u003e(f: (a: A) =\u003e B, g: (b: B) =\u003e C) =\u003e (a: A) =\u003e C\r\n```\r\n\r\nThe current version of TS allows me to do this and get the correct type:\r\n\r\n```typescript\r\nconst comp = compose(\u003cT\u003e(t: T) =\u003e t, \u003cT\u003e(t: T) =\u003e t); // comp: \u003cT\u003e(a: T) =\u003e T\r\n```\r\n\r\nBut say I want to wrap the result in an object:\r\n\r\n```typescript\r\ndeclare const composeObj: \u003cA, B, C\u003e(f: (a: A) =\u003e B, g: (b: B) =\u003e C) =\u003e { value: (a: A) =\u003e C }\r\n```\r\n\r\nNow the generic is gone, and `comp` above is typed as `{ value: (a: unknown) =\u003e unknown }`. \r\n\r\nI think what's happening is that TS is trying to put the `T` variable outside the scope of the object because if, instead of a wrapping object, I use a wrapping function, this is what happens:\r\n\r\n```typescript\r\ndeclare const composeFun: \u003cA, B, C\u003e(f: (a: A) =\u003e B, g: (b: B) =\u003e C) =\u003e () =\u003e (a: A) =\u003e C\r\nconst comp = composeFun(\u003cT\u003e(t: T) =\u003e t, \u003cT\u003e(t: T) =\u003e t); // comp: \u003cT\u003e() =\u003e (a: T) =\u003e T\r\n```\r\n\r\nTS is putting `T` on the outer level, so if I call `comp()` the result will be `(a: unknown) =\u003e unknown`.  A better result would've been to get `() =\u003e \u003cT\u003e(a: T) =\u003e T`. This way, calling `comp()` would not discard the type variable and, if I'm not mistaken, the result would be a more general type than the result we currently get, without breaking any typing rules.\r\n\r\n## 💻 Use Cases\r\n\r\nBeing able to wrap generic functions when they're the result of type inference. My specific case was writing a type guarding/converting utility using a wrapper around functions of the form `a -\u003e Maybe\u003cb\u003e` that can be chained together by the dot operator to represent function composition, such that types can be further specified. Something like `Thing.isPrimitive.isNumber.isInteger`. But this is not possible without the possibility to wrap the result of my `compose` function. \r\n","author":{"url":"https://github.com/jsoldi","@type":"Person","name":"jsoldi"},"datePublished":"2022-06-12T18:30:53.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":3},"url":"https://github.com/49505/TypeScript/issues/49505"}