Removing null and undefined from a Tuple breaks equality

Bug Report

When trying to remove nils from a Tuple it resolves to an Tuple that do not extends to the identical Tuple (as represented by the compiler)

So in the example below the reult of a type is [a: 1, b?:2] which do not extends the type [a: 1, b?:2] ??

🔎 Search Terms

Identical type - Invalid Equality
tuple optional extends

🕗 Version & Regression Information

Discovered the issue today and it's referenced on the following stackoverflow
I did test it in the playground upto version 4.05 of typescript (syntax breaks in version prior)

⏯ Playground Link

playground

💻 Code

type UnNullify<T extends readonly unknown[]> = {
  [K in keyof T]: Exclude<T[K], null | undefined>
}

type Foo = UnNullify<[a: 1, b?: 2 | undefined]>
//   [a: 1, b?: 2]

type Test = [a: 1, b?: 2] extends Foo ? true : false
//   false ??

🙁 Actual behavior

Two types represented identical by the compiler do not extends each other

🙂 Expected behavior

Expected the two types to extends

More search terms: tuple optional extends

In case it matters, this does look specific to optional tuple elements and not to optional properties in general:

type Checkit<T> = [T] extends [{ [K in keyof T]: Exclude<T[K], undefined> }] ? true : false;
type X = Checkit<{ x?: 0 }> // true
type Y = Checkit<[x?: 0]> // false?!

Playground link to code

Joe Calzaretta (@jcalz)

To expand Joe Calzaretta (@jcalz) post it is not relevant to labels and does not work either with unlablelled tuples

type Checkit<T> = [T] extends [{ [K in keyof T]: Exclude<T[K], undefined> }] ? true : false;
type X = Checkit<{ x?: 0 }> // true
type Y = Checkit<[0?]>      // false

Playground link

Expected the two types to extends

I don't think so. Instead I would expect UnNullify<[a: 1, b?: 2 | undefined]> to be [a: 1, b: 2].

The definition { [K in keyof T]: Exclude<T[K], null | undefined> } indicates that for any key of T it will resolve to a value which can never be null or undefined, and also note that Foo[1] resolves to 2(while [a: 1, b?: 2][1] resolves to 2 | undefined), which exactly matches the definition.

Instead I would expect UnNullify<[a: 1, b?: 2 | undefined]> to be [a: 1, b: 2].

It's a homomorphic mapped type, so it preserves the ? modifier. In any case, the result is [a: 1, b?: 2], and that result apparently does not extend [a: 1, b?: 2], despite that apparently being exactly the same type.

A bit of further investigation reveals that the type written as [a: 1, b?: 2] gets expanded to [a: 1, b?: 2 | undefined] in an error message, and this distinction appears to be why it doesn't count as extending the other type.

declare const bar: [a: 1, b?: 2];
const foo: Foo = bar;

Type '[a: 1, b?: 2 | undefined]' is not assignable to type '[a: 1, b?: 2]'.
  Type at position 1 in source is not compatible with type at position 1 in target.
    Type '2 | undefined' is not assignable to type '2'.
      Type 'undefined' is not assignable to type '2'.(2322)

Playground Link

However, when the exactOptionalPropertyTypes flag is enabled, so that writing [a: 1, b?: 2] does not expand to include undefined in the second component, the error message is different, and rather surprising:

Type '[a: 1, b?: 2]' is not assignable to type '[a: 1, b?: 2]'. Two different types with this name exist, but they are unrelated.
  'number' index signatures are incompatible.
    Type '1 | 2 | undefined' is not assignable to type '1 | 2'.
      Type 'undefined' is not assignable to type '1 | 2'.(2719)

Anders Hejlsberg (@ahejlsberg)

Anders Hejlsberg (@ahejlsberg) I think this is because when we compare source and target tuples, we just look at the type arguments and forget to re-introduce the undefined type.

Here's a test case that might be useful - it demonstrates different results between optional
object-declared properties and tuple elements.

// @strict: true, false
// @exactOptionalPropertyTypes: true, false

type UnNullify<T> = {
    [K in keyof T]: Exclude<T[K], null | undefined>
};

namespace tups {
    type ExplicitUndefined = [a: 1, b?: 2 | undefined];
    type ImplicitUndefined = [a: 1, b?: 2];
    type UnnullifiedExplicit = UnNullify<ExplicitUndefined>;
    type UnnullifiedImplicit = UnNullify<ImplicitUndefined>;

    type ExpectExtends<U extends T, T> = unknown;

    type Test1 = ExpectExtends<UnnullifiedExplicit, ExplicitUndefined>;
    type Test2 = ExpectExtends<UnnullifiedImplicit, ExplicitUndefined>;
    type Test3 = ExpectExtends<UnnullifiedExplicit, ImplicitUndefined>;
    type Test4 = ExpectExtends<UnnullifiedImplicit, ImplicitUndefined>;
    type Test5 = ExpectExtends<ExplicitUndefined, UnnullifiedExplicit>;
    type Test6 = ExpectExtends<ExplicitUndefined, UnnullifiedImplicit>;
    type Test7 = ExpectExtends<ImplicitUndefined, UnnullifiedExplicit>;
    type Test8 = ExpectExtends<ImplicitUndefined, UnnullifiedImplicit>;

    declare const expTup: ExplicitUndefined;
    declare const impTup: ImplicitUndefined;
    declare const nonNullExpTup: UnnullifiedExplicit;
    declare const nonNullImpTup: UnnullifiedImplicit;

    declare function a(a: ExplicitUndefined, b: UnnullifiedExplicit): void;
    a(expTup, nonNullExpTup);
    a(nonNullExpTup, expTup);
    a(impTup, nonNullImpTup);
    a(nonNullImpTup, impTup);

    declare function b(a: ImplicitUndefined, b: UnnullifiedImplicit): void;
    b(expTup, nonNullExpTup);
    b(nonNullExpTup, expTup);
    b(impTup, nonNullImpTup);
    b(nonNullImpTup, impTup);
}

namespace objs {
    type ExplicitUndefined = { a: 1, b?: 2 | undefined };
    type ImplicitUndefined = { a: 1, b?: 2 };
    type UnnullifiedExplicit = UnNullify<ExplicitUndefined>;
    type UnnullifiedImplicit = UnNullify<ImplicitUndefined>;

    type ExpectExtends<U extends T, T> = unknown;

    type Test1 = ExpectExtends<UnnullifiedExplicit, ExplicitUndefined>;
    type Test2 = ExpectExtends<UnnullifiedImplicit, ExplicitUndefined>;
    type Test3 = ExpectExtends<UnnullifiedExplicit, ImplicitUndefined>;
    type Test4 = ExpectExtends<UnnullifiedImplicit, ImplicitUndefined>;
    type Test5 = ExpectExtends<ExplicitUndefined, UnnullifiedExplicit>;
    type Test6 = ExpectExtends<ExplicitUndefined, UnnullifiedImplicit>;
    type Test7 = ExpectExtends<ImplicitUndefined, UnnullifiedExplicit>;
    type Test8 = ExpectExtends<ImplicitUndefined, UnnullifiedImplicit>;

    declare const expObj: ExplicitUndefined;
    declare const impObj: ImplicitUndefined;
    declare const nonNullExpObj: UnnullifiedExplicit;
    declare const nonNullImpObj: UnnullifiedImplicit;

    declare function a(a: ExplicitUndefined, b: UnnullifiedExplicit): void;
    a(expObj, nonNullExpObj);
    a(nonNullExpObj, expObj);
    a(impObj, nonNullImpObj);
    a(nonNullImpObj, impObj);

    declare function b(a: ImplicitUndefined, b: UnnullifiedImplicit): void;
    b(expObj, nonNullExpObj);
    b(nonNullExpObj, expObj);
    b(impObj, nonNullImpObj);
    b(nonNullImpObj, impObj);
}

A shorter example of the issue:

type UnNullify<T> = { [K in keyof T]: NonNullable<T[K]> };

const x: UnNullify<[string, number?]> = ['abc'];  // Property '1' is still optional
const x1 = x[1];  // number, but should be number | undefined

The UnNullify type removes undefined from the element type, but it doesn't remove optionality. Therefore, the 1 property is still optional (as demonstrated by the assignment to x) and it's type should still include undefined.

The proper way to "un-nullify" a type would be:

type UnNullify<T> = { [K in keyof T]-?: NonNullable<T[K]> };

Notice the -? modifier that strips optionality. When this type is used in the example above, the assignment to x fails as expected, and only then is it sound for property 1 to have type number.

Navigation Menu

Repository navigation

Removing null and undefined from a Tuple breaks equality #50753

Bug Report

🔎 Search Terms

🕗 Version & Regression Information

⏯ Playground Link

💻 Code

🙁 Actual behavior

🙂 Expected behavior

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Removing null and undefined from a Tuple breaks equality #50753

Description

Bug Report

🔎 Search Terms

🕗 Version & Regression Information

⏯ Playground Link

💻 Code

🙁 Actual behavior

🙂 Expected behavior

Activity

kaya3 commented on Sep 13, 2022

jcalz commented on Sep 13, 2022

zedryas commented on Sep 14, 2022

whzx5byb commented on Sep 14, 2022

kaya3 commented on Sep 14, 2022

kaya3 commented on Sep 14, 2022

DanielRosenwasser commented on Sep 16, 2022

ahejlsberg commented on Sep 19, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions