GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||||||||||
GeezerVison is showing github.com — Preserve the distributivity of inlined conditional types in declaration emit by weswigham · Pull Request #48592 · microsoft/TypeScript Conversation
|
| export {}; | ||
| //// [api.d.ts] | ||
| export declare const dropPrivateProps1: <Obj>(obj: Obj) => { [K in import("./internal").PublicKeys1<keyof Obj>]: Obj[K]; }; | ||
| export declare const dropPrivateProps2: <Obj>(obj: Obj) => { [K in keyof Obj extends infer T ? T extends keyof Obj ? T extends `_${string}` ? never : T : never : never]: Obj[K]; }; |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
T extends `_${string}` bit will never actually have anything to distribute over because the distribution is done one level up.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
The other thing I was curious about is whether we could ever just copy the unreachable type alias declaration to a local one. If we’re already copying its contents, why not just drop the whole declaration nearby with a unique name?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Wherever we can, we do (specifically if we can preserve it as-is, in it's existing location). We only do inlining like this when the type comes from somewhere unreachable or elided (like inside a different module's locals or an elided function body). We don't copy from those scopes into the current scope because then we'd have to do 1. pull in its whole dependency tree of types (which may, in turn, depend on things we just can't copy, like signature type parameters), and 2. ensure everything is renamed in such a way where there's no name conflicts. It's just not something we do much of right now.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
pull in its whole dependency tree of types
This is what I thought at first, but don’t we end up having to do that if we inline it too? Like the only part of the type that we don’t copy is the declaration.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
Declaration emit may change type semantics when inlining conditional types
There was an error while loading. Please reload this page.