Why isn't `value` being automatically narrowed to type `number` in this example?

I don't understand why "value" isn't narrowed to number in this TypeScript function. I'm thinking, if T is Property.Height then Data[T] should be of type Data[Property.Height] which is number

enum Property {
    Height = 'height',
    Name = 'name',
    DateOfBirth = 'date_of_birth'
}

interface Data {
    [Property.Height]: number;
    [Property.Name]: string;
    [Property.DateOfBirth]: Date;
}

function example<T extends Property>(value: Data[T], property: T) {
    if (property === Property.Height) {
        // why isn't "value" narrowed to number here?
    }
}

TypeScript is not currently able to use control flow analysis to affect generic type parameters like T inside the body of example. So while checking property === Property.Height will narrow the type of property, the T type parameter itself will stubbornly stay the same.

One reason T doesn't change is because it is not correct to say that checking property === Property.Height implies that T is Property.Height. The constraint T extends Property doesn't mean "T is exactly one of the union members of Property". It can be any subtype of Property, including the full Property union itself. Let's see what happens if we call example()` with union types:

// this does not cause a compiler error:
example(new Date(), Math.random() < 0.001 ? Property.DateOfBirth : Property.Height); 

// function example<Property.Height | Property.DateOfBirth>(
//    value: number | Date, property: Property.Height | Property.DateOfBirth
// ): void

That call is allowed, and you can see that T has been inferred to be the union Property.Height | Property.DateOfBirth, which means that Data[T] is inferred to be number | Date. In that call there is a 99.9% chance that property === Property.Height while value is definitely Date. Oops.

There is a longstanding open feature request at microsoft/TypeScript#27808 asking for some other syntax instead of T extends Property.. maybe say something like T oneof Property meaning that T must be exactly one member of the Property union. And then maybe the compiler could use property === Property.Height to conclude that T is Property.Height and you'd get the behavior you want. But for now it's not part of the language.

Right now, if you want to use if/else or switch/case case analysis inside your function, generics won't really help you. Instead, the supported way to do that is with discriminated unions. I could refactor that code to look like:

type ExampleArgs = { [K in Property]: [value: Data[K], property: K] }[Property]
/* type ExampleArgs = 
  [value: number, property: Property.Height] | 
  [value: string, property: Property.Name] | 
  [value: Date, property: Property.DateOfBirth] 
*/

function example(...[value, property]: ExampleArgs) {
  if (property === Property.Height) {
    value.toFixed(); // works
  }
}


example(new Date(), 
  Math.random() < 0.001 ? Property.DateOfBirth : Property.Height); // error!  
example(new Date(), Property.DateOfBirth); // okay  

I don't want to digress too much to explain how that was computed, but you can see that now example isn't generic; instead it takes a rest parameter of a discriminated union type, where the second argument discriminates the argument list. And you can't make bad calls with it anymore, as shown above.

Playground link to code