Type narrowing should be able to make generics irrelevant

[ShacharHarshuv]

Bug Report

⏯ Playground Link

Playground link with relevant code

💻 Code

type Ref<T> = {
  value: T | null;
}

function convertRef<T, U>(ref: Ref<T>, callback: (t: T) => U): Ref<U> {
  if (ref.value === null) {
    return ref; // error: Type 'Ref<T>' is not assignable to type 'Ref<U>'
  }

  return {
    value: callback(ref.value),
  }
}

🙁 Actual behavior

There is an error on: Type 'Ref' is not assignable to type 'Ref'

🙂 Expected behavior

Because of the if condition, ref value should be narrowed to { value: null }, which should be assignable to Ref<U>, so there shouldn't be any error.

(The ticket name might not be the best, feel free to rename if needed)

[fatcerberus]

You’re essentially asking for higher-order behavior whereby the compiler could recognize that a .value of null means this particular value is assignable to any instantiation of Ref regardless of the type argument, but that’s not how type narrowing works. You have a Ref<T> when you start, you still have a Ref<T> afterwards, which is not typewise compatible with Ref<U>.

[ShacharHarshuv]

Couldn't it be possible to narrow Ref<T> to Ref<never> so it's assignable to Ref<U>?

[xuld]

{ value: null } should not be assignable to Ref because U can be instantiated with other types.
If your code compiles without error , then the type of result is confusing, for example:

var result = convertRef<1, 2>({ value: null  }, t => 2)

[jcalz]

Duplicate of (or variant of) #42384

[fatcerberus]

Well, #42384 is probably a prerequisite for the code as written in the OP, but this one is more “have TS recognize when a subset of Foos are assignable to Bar” which is a whole different can of worms.

[ShacharHarshuv]

{ value: null } should not be assignable to Ref because U can be instantiated with other types. If your code compiles without error , then the type of result is confusing, for example:

var result = convertRef<1, 2>({ value: null  }, t => 2)

I'm not sure I understand. The inferred type of the result is correct. There would be no bug in your code. null is always a valid value based on the definition of Ref

[ShacharHarshuv]

Duplicate of (or variant of) #42384

I read the other issue but I don't understand enough about the TS compiler to say if fixing it would indeed also fix this issue.

[jcalz]

Without #42384, ref.value being narrowed to null doesn’t cause ref to be narrowed to {value: null} automatically. If that were changed, then you would presumably be able to return the narrowed ref as a value of type Ref<U>.

[rhazarian]

Consider this code if the function worked as you wanted in your example.

const numberRef: Ref<number> = {
    value: null,
};
const numberRefConvertedToStringRef = convertRef(numberRef, () => "");
numberRefConvertedToStringRef.value = "hello world";
const x = numberRef.value; // inferred type of x is number, but actually it is a string

I don't think that this sort of narrowing should be possible, maybe except when the object is readonly.

[fatcerberus]

@rhazarian TS generally doesn’t account for object mutability in assignability checks anyway; this wouldn’t be any different in that regard. { foo: number } is already assignable to { foo: unknown }, for example.

[RyanCavanaugh]

The proposed behavior is, in general, not sound.

type Ref<T> = {
  value1: T | null;
  value2: T | null;
}

function convertRef<T, U>(ref: Ref<T>, callback: (t: T) => U): Ref<U> {
  if (ref.value1 === null) {
    return ref;
  }
}

const m = convertRef({value1: null, value2: ""}, () => 32);
m.value2; // number | null, is string

[fatcerberus]

@RyanCavanaugh I believe the implied FR is for TS to detect when a narrowing like in the OP makes the type parameter irrelevant (in your example T remains in play because .value2 isn't narrowed), but like I said above, that implies higher-order analysis (detecting subsets of types that don't use the type parameter) that TS isn't capable of doing.

[ShacharHarshuv]

@RyanCavanaugh As @fatcerberus said, according to what I propose, your example should still throw an error, because {value1: null, value2: T | null} is not assignable to {value1: U | null, value2: U | null}. While in my example {value: null} is actually assignable to {value: U}.

detecting subsets of types that don't use the type parameter

I'm not sure I understand why it's that complicated. In my understanding, the if narrows the type to {value: null} and today, the following will not give an error:

type Ref<T> = {
  value: T | null;
}

function convertRef<T, U>(ref: Ref<T>, callback: (t: T) => U): Ref<U> {
  if (ref.value === null) {
    return { value: null }; // hard coded for the example, not giving an error
  }

  return {
    value: callback(ref.value),
  }
}

The problem is the type narrowing itself, not the assignability checks. Actually, it turns out you don't need generic to reproduce the problem:

declare const ref: { value: unknown };

if (ref.value === null) {
  const x: { value: null} = ref; // gives error
}

However, with simple primitives, it works:

declare const value: unknown;

if (value === null) {
  const x: null = value;
}

[jcalz]

looks meaningfully at #42384