optional elements in objects cannot be ensured to be defined

[dcermak]

TypeScript Version: 3.9.7, 4.0.0 beta, Nightly

Search Terms: required elements, type assertions

Code

interface Foo {
    element: number;
    optionalElement?: string;
}

// this one does not work, it fails to compile because optionalElement's type is incompatible
function toRequired(foo: Foo): Required<Foo> {
    if (foo.optionalElement === undefined) { throw new Error("element is undefined"); }

    return foo;
}

// this works
function toRequired2(foo: Foo): Required<Foo> {
    if (foo.optionalElement === undefined) { throw new Error("element is undefined"); }

    const { optionalElement, ...rest } = foo;
    return { optionalElement, ...rest };
}

Expected behavior:

It would be nice if toRequired would compile as well, as typescript knows that optionalElement is defined (as demonstrated in toRequired2.

Actual behavior:

toRequired fails to compile and requires either destructuring or type casts.

Playground Link:

Playground Link

[MartinJohns]

It would be nice if toRequired would compile as well, as typescript knows that optionalElement is defined (as demonstrated in toRequired2.

It also knows that the object can still be mutated:

const foo: Foo = { element: 0, optionalElement: 'test' };
const requiredFoo: Reqired<Foo> = toRequired(foo);

foo.optionalElement = undefined;
requiredFoo.optionalElement; // Now undefined as well!

[dcermak]

It would be nice if toRequired would compile as well, as typescript knows that optionalElement is defined (as demonstrated in toRequired2.

It also knows that the object can still be mutated:

const foo: Foo = { element: 0, optionalElement: 'test' };
const requiredFoo: Reqired<Foo> = toRequired(foo);

foo.optionalElement = undefined;
requiredFoo.optionalElement; // Now undefined as well!

That is a good point actually! But if optionalElement is declared as readonly, then toRequired still does not compile and the above snippet no longer works.

[MartinJohns]

But if optionalElement is declared as readonly, then toRequired still does not compile and the above snippet no longer works.

I feel compelled to mention that readonly does not mean "immutable", and the property is only read-only via that interface. Interfaces with readonly properties are implicitly compatible with mutable interfaces.

interface ReadonlyData { readonly data: string; }
interface MutableData { data: string; }

function mutateData(obj: MutableData) { obj.data = 'example'; }

const data: ReadonlyData = { data: 'test' };
mutateData(data);

[dcermak]

But if optionalElement is declared as readonly, then toRequired still does not compile and the above snippet no longer works.

I feel compelled to mention that readonly does not mean "immutable", and the property is only read-only via that interface. Interfaces with readonly properties are implicitly compatible with mutable interfaces.

I did not know that. Honestly, in that case I am actually not sure anymore if toRequired should even work the way I would like it to.

[jcalz]

Duplicate of #16976, I think.

I don't see mutations as being the main issue here; control flow analysis could presumably narrow upon checking and then re-widen upon an assignment, much as it does in this case:

function toRequired(foo: string | undefined): string {
    if (foo === undefined) { throw new Error("element is undefined"); }
    return foo; // okay
}

function toRequiredBad(foo: string | undefined): string {
    if (foo === undefined) { throw new Error("element is undefined"); }
    foo = undefined; // I mutated it
    return foo; // error here
}

It's mostly that the compiler does not attempt to narrow the type of non-union-typed values, even if they contain properties that are themselves union types. I imagine performance would take a major hit if every check of a union-typed value had implications for any values depending on it.

Discriminated unions are possibly a way to proceed here, since they're one of the few places (or only place?) in which checking an object's property can narrow the type of the object itself. It still has to be a union-typed object, though, like this:

type Foo = ({ element: number }) & ({ optionalElement: string } | { optionalElement?: undefined });

function toRequired(foo: Foo): Required<Foo> {
    if (foo.optionalElement === undefined) { throw new Error("element is undefined"); }
    foo.optionalElement = undefined; // error, won't let you mutate
    return foo; // okay
}

[RyanCavanaugh]

Duplicate #10065

[dcermak]

Since #10065 was closed and locked, you're essentially saying that this won't be fixed/changed?

[RyanCavanaugh]

Never say never, but it's unlikely to be any time soon. It would require a fairly invasive rethinking of how the checker reasons about types.

[typescript-bot]

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.