Distinguish missing and undefined

TypeScript Version: 2.1.4

Code

Current, with --strictNullChecks on, the typescript compiler seems to treat

interface Foo1 {
  bar?: string;
}

and

interface Foo2 {
  bar?: string | undefined;
}

as being the same type - in that let foo: Foo1 = {bar: undefined}; is legal. However, this does not seem to be the original intent of the language - while some people have used ? as a shortcut for | undefined (e.g. #12793 (comment)), it seems that the intent of the operator was to signify that the property either did not appear, or appeared and is of the specified type (as alluded in #12793 (comment)) - which might not include undefined - and in particular it would let us write types that either have a property that, if enumerable is not undefined, or is not present on the object.

In other places it might make sense for ? to keep serving as a shorthand for | undefined, e.g. for function parameters. (or maybe for consistency it would make sense to stick with it meaning "always pass something undefined if you pass anything"? not sure what's best there. Happy to discuss.)

Expected behavior:

interface Foo1 {
  bar?: string;
}
function baz(bar: string) {};

let foo: Foo1 = {bar: undefined}; // type error: string? is incompatible with undefined

if (foo.hasOwnProperty("bar")) {
  baz(foo.bar); // control flow analysis should figure out foo must have a bar attribute here that's not undefined
}
if ("bar" in foo) {
  baz(foo.bar); // control flow analysis should figure out foo must have a bar attribute here that's not undefined
}

Actual behavior:

interface Foo1 {
  bar?: string;
}
function baz(bar: string) {};

let foo: Foo1 = {bar: undefined}; // compiler is happy

if (foo.hasOwnProperty("bar")) {
  baz(foo.bar); /*  error TS2345: Argument of type 'string | undefined' is not assignable to parameter of type 'string'.  Type 'undefined' is not assignable to type 'string'*/

}
if ("bar" in foo) {
  baz(foo.bar); /* error TS2345: Argument of type 'string | undefined' is not assignable to parameter of type 'string'.  Type 'undefined' is not assignable to type 'string'*/
}

I agree, in JS there is a difference between the two

const a = { prop: undefined };
a.prop // undefined
a.hasOwnProperty('prop') // true
'prop' in a // true
for (k in a) {
  console.log(k) // logs 'prop'
}

const b = { };
b.prop // undefined
b.hasOwnProperty('prop') // false
'prop' in b // false
for (k in b) {
   console.log(k) // never hit
}

I wrote that comment you referenced. I go back and forth on this. The devil's advocate position is that, under the proposed stricter interpretation of ?, I'll still be able to assign {} to Foo, and thus, I still must treat foo.bar as string | undefined at all places in my code. The only thing I can see being achieved with this higher level of strictness is a new way of type guarding a value for which a perfectly good type guard is already available.

Instead of looking at keys, you can accomplish the type inference you want right now by looking at values.

interface Foo {
  bar?: string;
}
function baz(bar: string) {};

let foo1: Foo = {bar: undefined}; // would become type error: string? is incompatible with undefined
let foo2: Foo = {}; // Would still, however, be allowed

if (typeof foo1.bar !== 'undefined') {
    baz(foo1.bar); // Control flow already correctly narrows type to string
    baz(foo2.bar); // Control flow correctly warns that this could be undefined (under strictNullChecks)
}

So, if there is a specific key in mind, there is already a clean way of type guarding it.

Is the difference more pertinent when enumerating a whole object by keys? I couldn't construct a case in which it is.

for (let k of foo) {
    let val = foo1[k]; // Would still be any under strictOptionalMember, and still an error under noImplicitAny
}

Possibly some meaningfully different expression could be constructed using lookup types. But I almost think it's a code smell to care about whether a key exists on an object.

The bird's eye view is that JavaScript intends for the developer to equivocate between "no key" and "key: undefined". Thinking about the existence of a key is generally not a very useful paradigm in JavaScript. Instead, what really matters are the possible types of the values. So while this new way might be more faithful to the mechanics of JavaScript, it's not more faithful to the intended usage of JavaScript.

I have met JavaScript libraries that used 'prop' in options or options.hasOwnProperty('prop') to check for the presence of an option, and then when you pass undefined (because you just pass your own optional parameter for example) it results in bugs TypeScript didn't catch.

That's a strong argument. It's good for TypeScript's type system to be able to express whatever is possible in JS, whether or not those possibilities are a good idea.

yeah... if I was designing javascript from scratch, I'd probably leave out the whole concept of undefined. But it exists in js, and I don't think typescript is willing to try to change that, so we have to live with it. Making it possible to distinguish, in the type system, between an attribute existing or not without making that attribute optionally undefined would be useful, since we are working with a language that has these (perhaps unnecessary) complexities.

The current missing/undefined convolution does seem potentially problematic...

const x: {a?: string} = {a: undefined}; // expect error, but passed

Is it possible to introduce void to mean "missing" and leave undefined as undefined? So { foo?: string } would be equivalent to { foo: string | void }?

Where does this issue currently stand? Is it something under consideration, or are there reasons why we can't fix this?

Update: separate issue with reduced test case #35983

Another example where TypeScript's inability to distinguish missing from undefined leads to inconsistencies between the types and JavaScript's actual behaviour is usage of object spread.

A real world example of this pattern is a withDefaults higher-order React component.

type Props = {
    foo: string;
    bar: string
}

type InputProps = {
    foo?: string;
    bar: string;
}

const defaultProps: Pick<Props, 'foo'> = { foo: 'foo' };
const inputProps: InputProps = { foo: undefined, bar: 'bar' };

// Type of `foo` property is `string` but actual value is `undefined`
const completeProps: Props = { ...defaultProps, ...inputProps };

$ node
> const defaultProps = { foo: 'foo' };
undefined
> const inputProps = { foo: undefined, bar: 'bar' };
undefined
> const completeProps = { ...defaultProps, ...inputProps };
undefined
> completeProps
{ foo: undefined, bar: 'bar' }

Ideally, this would throw a type error:

// `{ foo: undefined; bar: string; }` is not assignable to `{ foo?: string; bar: string; }`
const inputProps: InputProps = { foo: undefined, bar: 'bar' };

On the other hand, if TypeScript did purposely not distinguish between missing and undefined, TypeScript should instead emit an error when spreading:

// `{ foo: string | undefined; bar: string }` is not assignable to `Props`
const completeProps: Props = { ...defaultProps, ...inputProps };

I believe this is related to an issue I'm having exporting a hoc withRouter from a component library to another project (using TS 2.8.3).

This hoc has own props like (notice that prop3 is optional):

type OwnProps = {
  prop1: string;
  prop2: string;
  prop3?: string;
};

which causes the component to be default exported in the compiled code as:

React.ComponentClass<Pick<OwnProps, "prop1" | "prop2" | "prop3" | undefined>>;

Raising the error:

Type 'undefined' is not assignable to type '"prop1" | "prop2" | "prop3"'.

I had to work around making the optional props mandatory, explicitly accepting undefined as their union type:

type OwnProps = {
  prop1: string;
  prop2: string;
  prop3: string | undefined;
};

Does this make sense? Is this still up?

It would be useful now to be able to define whether a property should be on an object or not based on some conditional type.

type Foo<CK extends string, NK extends string> = {
  ...
  extraMappings: Exclude<NK, CK> extends never ? missing : {something: string}
}

You can use undefined currently but as discussed it's not quite the same.

🤖 Merge PR DefinitelyTyped#46226 react-big-calendar: improve types, f…

Any updates on this one? Does seem to be unfortunate that

interface Foo1 {
  bar?: string;
}

permits 3 possible runtime states to handle.

I scanned through all of the above comments to see if somebody else had already mentioned this use case regarding index signatures, but I couldn't find anything, so here goes.

declare const partial: { foo?: string };
// Unexpected error! ❌
// Type 'undefined' is not assignable to type 'string'.
const dictionary: { [key: string]: string } = partial;

Update: the above error no longer reproduces in 4.2 due to this change: https://devblogs.microsoft.com/typescript/announcing-typescript-4-2-rc/#relaxed-rules-between-optional-properties-and-string-index-signatures (#41921).

and

type Dict<T> = { [key: string]: T }
interface F extends Dict<string> {
    // Property 'foo' of type 'string | undefined' is not assignable to string index type 'string'.
    foo?: string;
}

Here is the same issue reported on StackOverflow: https://stackoverflow.com/questions/64505407/coercing-type-with-optional-properties-to-an-indexable-type

If TypeScript distinguished between missing and undefined then I believe this would not produce an error. That is because the optional property would not add undefined to the property value type.

Real world use case: I'm trying to convert an object with an optional property into a Json type.

type Json = boolean | number | string | null | JsonArray | JsonRecord;
interface JsonRecord {
    readonly [key: string]: Json;
}
interface JsonArray extends ReadonlyArray<Json> {}

type User = { name?: string };

const user: User = { name: 'bob' };

declare const stringifyJSON: (json: Json) => string;
// Unexpected error! ❌
// Type 'undefined' is not assignable to type 'Json'.
const string = stringifyJSON(user);

// Unexpected error! ❌
// Type 'undefined' is not assignable to type 'Json'.
const userJson: Json = user;

Workarounds I'm aware of:

In JsonRecord, add undefined to the index signature
```
 interface JsonRecord {
-    readonly [key: string]: Json;
+    readonly [key: string]: Json | undefined;
 }
```
However this feels like we're creating another problem because now the JSON type is incorrect—JSON objects cannot contain undefined values, but this type will allow objects which contain undefined values.
In JsonRecord, replace the index signature with a mapped type and mark all properties as optional:
```
-interface JsonRecord {
-    readonly [key: string]: Json;
-}
+export type JsonRecord = { readonly [Key in string]?: Json };
```
This is probably better than the previous workaround because we're declaring the property as optional. However, this will still allow objects which contain undefined values, due to the fact that TypeScript does not distinguish between missing and undefined. Example of a library using this workaround: Allow all keys to be optional in the JsonObject type sindresorhus/type-fest#65

Here's a stripped down version of a real world example I just ran into:

type PropertyNames = "foo" | "bar" | "baz"
type MyComplexObj = {thing: number, etc: string}

//There is no way to describe "an object with 0 or more keys from PropertyNames, values of type MyComplexObj"
//TS forces an undesired "| undefined" here
function makeSomeDefaults(): {[key in PropertyNames]?: MyComplexObj}{
    return {foo: {thing: 1, etc: "etc"}}
}

//Type '(MyComplexObj | undefined)[]' is not assignable to type 'MyComplexObj[]'.
//  Type 'MyComplexObj | undefined' is not assignable to type 'MyComplexObj'.
//   Type 'undefined' is not assignable to type 'MyComplexObj'.(2322)
const myDefaults: MyComplexObj[] = Object.values(makeSomeDefaults())

//To actually get what I intended, I need a superfluous _.compact
const myDefaults: MyComplexObj[] = _.compact(Object.values(makeSomeDefaults())

In this example the _.compact is superfluous. There are never going to be keys with undefined values returned from makeSomeDefaults but TS does not allow me to describe that.

Here's another real world example from one of my libraries called react-use-sub.

const initialState = { foo: 'bar', num: 2 };
const [useSub, Store] = createStore(initialState);

// allows to make partial updates to the state
// typeof Store['set'] = (updates: Partial<typeof initialState>) => void
Store.set({ foo: 'something' });

// but also allowed by TypeScript !!!
Store.set({ foo: undefined });

The latter operation would make the type of foo on state invalid if I would override it. Hence I have to ignore any undefined values and optional values have to be done with null instead 👎

This was the one of the few things that was better handled by Facebooks flow.

Sorry for a new not-so-relevant post but I just wanted to reply to last @fdc-viktor-luft comment.

The specific case you presented is better handled by Pick instead of Partial. I would made a signature more like this:

set<S, K extends keyof S>(state: Pick<S, K>): void;

Now TS will fail if you pass undefined to a prop that doesn't allow it explicitly. See playground. BTW, this is how setState is typed in React.

That being said I really believe that differentiate "missing" from undefined is necessary. Wish to see some progress on this.

Daniel Contreras (@InExtremaRes)

Daniel Contreras (@InExtremaRes) Wow 🤩 Thanks a lot. That really solves my particular problem, but it's not very obvious 😄

I totally agree with you 👍

Sharing my workaround:

type MakeOptionalNull<T> = Required<
  {
    [P in keyof T]: undefined extends T[P] ? T[P] | null : T[P];
  }
>;

type MakeNullUndefined<T> = {
  [P in keyof T]: null extends T[P] ? Exclude<T[P] | undefined, null> : T[P];
};

type RequireOptionalKeys<T> = MakeNullUndefined<MakeOptionalNull<T>>;

type A = {
  a?: number;
  b: number;
};

type B = RequireOptionalKeys<A>;

// type B = {
//    a: number | undefined;
//    b: number;
//}

This feature is now implemented in #43947.

I didn't expect this feature coming any time soon, especially since it's not even on the roadmap, and then BAM! Anders suddenly drops a feature-bomb on us.. again! ❤️

Navigation Menu

Repository navigation

Distinguish missing and undefined #13195

50 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Distinguish missing and undefined #13195

Description

Activity

felixfbecker commented on Dec 28, 2016

masonk commented on Dec 29, 2016

felixfbecker commented on Dec 29, 2016

masonk commented on Dec 29, 2016

dgoldstein0 commented on Jan 21, 2017

KiaraGrouwstra commented on Jul 20, 2017

jcalz commented on Aug 29, 2017

OliverJAsh commented on Mar 14, 2018

OliverJAsh commented on Mar 14, 2018

OliverJAsh commented on Mar 21, 2018

Fabianopb commented on May 15, 2018

leighman commented on Jun 8, 2018

50 remaining items

alexweej commented on Jan 20, 2021

OliverJAsh commented on Feb 9, 2021

evelant commented on Feb 17, 2021

vikingair commented on Feb 17, 2021

InExtremaRes commented on Mar 18, 2021

vikingair commented on Mar 19, 2021

kahoot-karl commented on Apr 16, 2021

ahejlsberg commented on May 4, 2021

MartinJohns commented on May 4, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions