Repository navigation
bug: operations failed unless separated #16244
Description
TypeScript Version: 2.3.1-insiders.20170416 (Playground, strictNullChecks off)
Code
Omit type for #12215:
// helpers...
type Obj<T> = { [k: string]: T };
type SafeObj<O extends { [k: string]: any }, Name extends string, Param extends string> = O & Obj<{[K in Name]: Param }>;
type SwitchObj<Param extends string, Name extends string, O extends Obj<any>> = SafeObj<O, Name, Param>[Param];
type Not<T extends string> = SwitchObj<T, 'InvalidNotParam', {
'1': '0';
'0': '1';
}>;
type UnionHas<Union extends string, K extends string> = ({[S in Union]: '1' } & { [k: string]: '0' })[K];
type Obj2Keys<T> = {[K in keyof T]: K } & { [k: string]: undefined };
// data...
type Item1 = { a: string, b: number, c: boolean };
// okay, Omit, let's go.
type Omit_<T extends { [s: string]: any }, K extends keyof T> =
{[P2 in keyof T]: { 1: Obj2Keys<T>[P2], 0: undefined }[Not<UnionHas<K, P2>>]}
type T1 = Omit_<Item1, "a">;
// intermediary result: { a: undefined; b: "b"; c: "c"; }
type T2 = {[P1 in T1[keyof Item1] ]: Item1[P1]}; // { b: number, c: boolean };
// ^ great, the result we want!
// now let's combine the steps?!
type Omit<T extends { [s: string]: any }, K extends keyof T> =
{[P1 in {[P2 in keyof T]: { 1: Obj2Keys<T>[P2], 0: undefined }[Not<UnionHas<K, P2>>]}[keyof T] ]: T[P1]};
type T3 = Omit<Item1, "a">;
// ^ yields { a: string, b: number, c: boolean }, not { b: number, c: boolean }
// uh, could we instead do the next step in a separate wrapper type?:
type Omit2<T extends { [s: string]: any }, K extends keyof T> = Omit_<T, K>[keyof T];
// ^ not complete yet, but this is the minimum repro of the part that's going wrong
type T4 = Omit2<Item1, "a">;
// ^ nope, foiled again! 'a'|'b'|'c' instead of 'b'|'c'... wth?
// fails unless this access step is done after the result is calculated, dunno whySimilar issue encountered in my attempt to calculate union differences to resolve #13470.
Expected behavior:
Operations can be combined so as to make more sophisticated types.
Actual behavior:
The compiler gets confused if the access step directly follows the previous half of the computation.
Edit: it appears #16018 is closer to a minimum repro of this same issue.
Activity
KiaraGrouwstra commentedon Jun 11, 2017
Fixed by nir (@nirendy) at #12215. 😃
KiaraGrouwstra commentedon Jun 29, 2017
Here's another occurrence that doesn't appears solved with those defaults:
KiaraGrouwstra commentedon Jun 30, 2017
Worked around this one by typing the last one differently altogether, making the root cause less urgent again. I'll re-close until a new blocker comes in I guess.