Problem with inference for this['prop'] with conditional types

[dfreeman]

TypeScript Version: typescript@3.1.0-dev.20180907
Search Terms: this type, conditional type

Code

type Wrapped<T> = { ___secret: T };
type Unwrap<T> = T extends Wrapped<infer U> ? U : T;

declare function set<T, K extends keyof T>(obj: T, key: K, value: Unwrap<T[K]>);

class Foo {
    prop: Wrapped<string>;

    method() {
        set(this, 'prop', 'hi'); // <-- type error
    }
}

set(new Foo(), 'prop', 'hi'); // <-- typechecks

Expected behavior:
Both calls to set (the one in the method with this and the external one with new Foo()) pass typechecking.

Actual behavior:
The external call passes, but the one inside method fails with Argument of type '"hi"' is not assignable to parameter of type 'Unwrap<this["prop"]>'..

If I explicitly annotate this: Foo in the method signature or set the type parameters set<Foo, 'prop'>(...), everything passes.

We've run into this in the Ember type declarations, and have had to weaken the types for the time being to work around it.

Playground Link: available here

Related Issues: I wasn't able to find anything that seemed related to this issue.

[weswigham]

From what I know of conditional types, the root issue is that we don't perform any inferences to conditional types and this in the class body is still generic, so requires successful inference to work correctly. #27012 may help here, but I'm not sure. It's certainly affected by the same area.

[dfreeman]

@weswigham thanks for the ping—I pulled and built master since that PR was merged, but still see the same error message with that sample code

[weswigham]

So, I've looked over it again, and while I do have a "fix" known, the desired behavior is unsound. Given

type Wrapped<T> = { ___secret: T };
type Unwrap<T> = T extends Wrapped<infer U> ? U : T;

declare function set<T, K extends keyof T>(obj: T, key: K, value: Unwrap<T[K]>): void;

class Foo {
    prop: Wrapped<string>;

    method() {
        set(this, 'prop', 'hi'); // <-- type error
    }
}

Consider subtype:

class Bar extends Foo {
  prop: Wrapped<"ohno">;
}
const x = new Bar();
x.method(); // We just set `prop` to `"hi"` even though this component only takes an `"ohno"`!

The "read" case of these types works fine:

type Wrapped<T> = { ___secret: T };
type Unwrap<T> = T extends Wrapped<infer U> ? U : T;

declare function get<T, K extends keyof T>(obj: T, key: K): Unwrap<T[K]>;

class Foo {
    prop: Wrapped<string>;

    method() {
        return get(this, 'prop'); // <-- fine
    }
}

class Bar extends Foo {
    prop: Wrapped<"ohyeah">;
}

const a = get(new Foo(), 'prop'); // <-- also fine

const b = get(new Bar(), 'prop'); // <-- also fine

for the set to be typesafe, you must set a type which varies appropriately with the class:

type Wrapped<T> = { ___secret: T };
type Unwrap<T> = T extends Wrapped<infer U> ? U : T;

declare function set<T, K extends keyof T>(obj: T, key: K, value: Unwrap<T[K]>): void;

class Foo {
    prop: Wrapped<string>;
    defaultProp: Unwrap<this["prop"]>; // note use of generic `this` type

    method() {
        set(this, 'prop', this.defaultProp); // <-- fine
    }
}

class Bar extends Foo {
    prop: Wrapped<"ohyeah">;
}

set(new Foo(), 'prop', "ok"); // <-- also fine

set(new Bar(), 'prop', "ohyeah"); // <-- also fine

so @DanielRosenwasser as is, this is working as intended.

[dfreeman]

You're right that the specific example I gave was unsound with the subclassing you're describing, but as far as I can tell, that's not unique to anything with conditional types or the wrapping that was going on:

class Foo {
  prop: string;
  method() {
    this.prop = 'hi';
  }
}

class Bar extends Foo {
  prop: 'ohno';
}

const x = new Bar();
x.method(); // We just set `prop` to `"hi"` even though this component only takes an `"ohno"`!

[weswigham]

For partly historical reasons, we have a rule that allows the unsound writes for primitive member types since thinking about variance in simple code is a heavy burden (and tbh it predates us tracking variance), however generics and indexed accesses in general track variance strictly and disapprove of the unsound assignments.