TypeScript: Distinguish missing and undefined

This feature is now implemented in #43947.

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
}

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

Update: separate issue with reduced test case https://github.com/microsoft/TypeScript/issues/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 };

we have over 3500+ files project and never run into this problem, however you put it, typescript has enough expression power to please you, not sure why it draws so much attention

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.

My main issue is with the unsoundness of the spread syntax:

const x: {foo?: number} = {foo: undefined}
const y: {foo: number} = {foo: 123, ...x}
console.log(y) // y is now {foo: undefined}

Another real world example where this matters.

React elements have their className prop marked as optional. However, this also allows undefined to be passed as a value, resulting in HTML of class="undefined":

<div className={undefined} />
// creates <div class="undefined" />

Update: I was wrong https://github.com/DefinitelyTyped/DefinitelyTyped/pull/57463#pullrequestreview-820042607

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! ❤️

The current missing/undefined convolution does seem potentially problematic…

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

This issue also manifests in Object.values() and Object.entries()

Playground

declare const rec: Partial<Record<string T>>;
Object.values(rec); // type: (T | undefined)[]

It would be nice to be able to safely describe an object that may be defined at a set of keys, but will never be defined as the value undefined.

Edit: For reference to an actual use case here, we have some Redux structures that cache items-by-id. So we need a record-like structure indexed on an arbitrary id. If we want to list all of the items in this cache, we end up using Object.values().

Started here: #30796

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.

This keeps coming up from time to time. We’d like to see a PR that implements this so we can roughly estimate its complexity and see what the breakage on Real World Code is. It shouldn’t be a super-difficult PR to sketch out the basics for.

Basic possible outcomes:

• Finds some real bugs or bug-like-things in RWC and doesn’t break too much else: Consider shipping under --strict with an opt-out
• Finds nothing interesting in RWC and breaks very little: Possibly same as above
• Breaks a ton of stuff: ❌

What about a ‑‑noImplicitUndefined compiler flag that would make optional parameters and properties not automatically allow undefined.

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

interface Foo1 {
  bar?: string;
}

permits 3 possible runtime states to handle.

Closed #38624 in favor of this one. I’ll add a note on this issue.

Here’s yet another example that leads to a runtime error:

interface B {
    b: number
}

interface A {
    a: B;
}

const fn = (arg: Partial<A>): A => ({a:{b:2}, ...arg});

let aRes = fn({a:undefined});
console.log(aRes.a.b);

I expected the program to fail to compile because any prop in Partial<A> can be explicitly set to undefined, which overrides it’s corresponding value when spreaded over another object of type A. This causes the return value of fn to not be described by A, but instead by an interface similar to A where all props can be undefined as well. But got: TypeError: "aRes.a is undefined" instead.

Playground Link: https://www.typescriptlang.org/play?ts=4.0.0-dev.20200516#code/JYOwLgpgTgZghgYwgAgELIN4Chm+QIwC5kQBXAW32iwF8stRJZEUBBTHPOY1AblvoIA9iADOYZDBDIAvMgAUcKAHNiABSVhgcADYAeVgD4AlMXYzDCjNwxEATDQA0yAHRulymsf5YdECXAAShCispIg8taEpCAAJhAwoBCxXvzCYkJ+LjpCyorBoi5wLvjeQA

Hmm, in #24897 (tuples in rest/spread positions):

Optional elements in tuple types

Tuple types now permit a ? postfix on element types to indicate that the element is optional:

let t: [number, string?, boolean?];

That makes me wonder if we might use T? (where T is a type) everywhere to mean “an optional parameter/property whose type, if not missing, is T”. So we allow the ? to jump from the parameter/key name to the type. That is, the following function signatures are nearly equivalent:

declare function foo(a?: string): void;
declare function foo(a: string?): void;

(modulo whether you want one or both of them to disallow foo(undefined)) and the following types are nearly equivalent:

type Foo = {a?: string};
type Foo = {a: string?};

(modulo whether you want one or both of them to disallow {a: undefined}). And the missing type would be equivalent to never?.

---

I find myself wanting this feature more now, since #26063 (mapped arrays/tuples), as away to programmatically add/remove optionality from tuples.

I would like to see this ability added. I commonly use an object as a dictionary, mapping strings to values.

interface Dictionary<T> {
    [key: string]: T;
}

In this case you are not sure which keys are in the object, but you know that if they are in the object they have a value of type T (i.e., not undefined). So what I want is this:

const d: Dictionary<number> = getDictionary();
const name: string = getName();

++d[name];            // should be an error; name may not be in d
                      // (currently accepted by TypeScript)

if (name in d) {
    ++d[name];        // should be OK; if name is in d, its value will be a number
}

for (let k in d) {
    d[k]++;           // should be OK; every key in d has a number value
}

Currently TypeScript does not flag the first increment as an error. I can understand that: it is necessary for TypeScript to assume you are using a valid key; otherwise using arrays would be tiresome. However, it would be nice if I could use the following type to mean that some keys may be missing, not to mean that some keys may have an undefined value.

interface Dictionary<T> {
    [key: string]?: T;
}

This currently does flag the first increment as an error, as desired. However, it also flags the second and third increments as errors since it assumes their values may be undefined. If TypeScript distinguished between missing keys and keys with an undefined value then I believe this second type would do what I want.

@robbiespeed well following ES6 semantics that should really be made possible with just

interface Foo<T = undefined> {
    bar(a: T): void
}

because according to ES6, passing undefined to a parameter is equivalent to passing no parameter - if you declared a default value for example, passing undefined will result in the default value being used, which would not be true for e.g. passing null.

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 (https://github.com/microsoft/TypeScript/pull/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: https://github.com/sindresorhus/type-fest/pull/65

I’ve hacked this by using tag-type 😃 May be this snippet will help anybody. Seems working for my case …

converting this type

type Foo = {
    optional?: 'my optional field';
    required: 'this is required field';
};

into this type

type Foo = {
    optional: 'my optional field' | undefined;
    required: 'this is required field';
};

snippet with example

type MY_TAG_FOR_UNDEFINED_FIELD = { id: 'MY_TAG_FOR_UNDEFINED_FIELD' };
type Tagged <T> = { [K in keyof T]-?: Extract<T[K], undefined> extends never ? T[K] : T[K] | MY_TAG_FOR_UNDEFINED_FIELD };
type Untagged <T> = { [K in keyof T]: Extract<T[K], MY_TAG_FOR_UNDEFINED_FIELD> extends never ? T[K] : Exclude<T[K], MY_TAG_FOR_UNDEFINED_FIELD> | undefined };

type RequiredButUndefined <T> = Untagged<Tagged<T>>;

type Foo = {
    optional?: 'my optional field';
    required: 'this is required field';
};

type FooRequiredButWithUndefinedUnion = RequiredButUndefined<Foo>;

const fooWithOptionalOK: FooRequiredButWithUndefinedUnion  = {
    optional: undefined,
    required: 'this is required field',
};
const fooWithOptionalOK_2: FooRequiredButWithUndefinedUnion  = {
    optional: 'my optional field',
    required: 'this is required field',
};
const fooWithoutOptional_ERROR_HERE: FooRequiredButWithUndefinedUnion  = {
    required: 'this is required field',
};

Playground Link

@jcalz I know 100% soundness isn’t a goal but this made me chuckle

function foo(x: string, y: number | void, z: boolean | void) { }

const f: () => void = () => "i am a string";
foo("x", f()); //Compiles

Playground

Because void doesn’t mean “missing” or undefined. It means “a value exists but you should not use it” or something to that effect.

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;
//}

I’m not sure I really agree that generics are an issue. IMO it just seems weird to ask a value if it is missing by consulting its type; by definition you have a value so it can’t be missing! The only thing that knows whether there should be a value there or not is the container, be it an object or function. Once you have a value, of possibly generic type, the concept of missing has already been lost. The semantics of the container determine how to interpret missing.

I don’t think is a problem that is ever going to be solved by adding a special type - it really needs to be pushed up a level to be a property of fields and arguments.

void is broken for a variety of reasons; I hope TypeScript 4.0 can readdress this now that void is largely redundant with unknown.

Note that void meaning “missing” has already been implemented for function parameters (with no trailing required parameters) in #27522:

function foo(x: string, y: number | void, z: boolean | void) { }
foo("a", 1, true); foo("a", 1); foo("a"); // okay

So that’s closer to this being a real thing. Of course there are still some outstanding bugs here (#29131); and it doesn’t yet work on object properties; and we can still call foo("a", undefined) so the part where this distinguishes “missing” from undefined isn’t there. But it’s a start, right?

For anyone still waiting for optional function arguments, it is now possible to simulate that using new tuple types and spread expressions.

type OptionalSpread<T = undefined> =
    T extends undefined
    ? []
    : [T]

const foo = <T = undefined>(...args: OptionalSpread<T>): void => {
    const arg = args[0] // Type of: T = undefined
}

// undefined inferred
foo()               // OK
foo(42)             // OK <----single argument type is inferred, can't do anything about it   

// undefined explicit
foo<undefined>()    // OK
foo<undefined>(42)  // ERROR Expected 0 arguments, but got 1.

// number
foo<number>(42)     // OK
foo<number>()       // ERROR Expected 1 arguments, but got 0.
foo<number>("bar")  // ERROR Argument is not assignable to parameter of type 'number'.

it has a limitation with inferred argument type though, which is solved by explicitly specifying undefined argument type

Unfortunately the optional tuples suffer from the same problem:

const a: [number, string?, boolean?] = [1];
const b: [number, string?, boolean?] = [1, undefined];
const c: [number, string?, boolean?] = [1, "string", undefined];
const d: [number, string?, boolean?] = [1, undefined, undefined];

I do think their is mileage in the syntax T? though I think it should just be a type with a meaning that is invariant of context. T? should say nothing about properties or arguments and be valid anywhere a type is. I think that T? is allowed in JsDoc types, though I’m not sure how this plays with TS.

Some my thinking would be something like: in strictMissingMode then

• { x?: string } means either the property is not present, or the property is explicitly present and the value is of type string. The ? is an attribute of the property, not the type string. Here string means exactly what it says.
• { x: string? } means that the property is explicitly present but the value is either of type string or undefined. The ? is an attribute of the type so string? means the same thing in all contexts. Essentially string? === (string | undefined).

The same would apply to function parameters, with the following behaviour.

type X = { x?: string };

const a: X = {}; // valid
const b: X = { x: "x" }; // valid
const c: X = { x: undefined }; // invalid

type Y = { y: string? };

const d: Y = {}; // invalid
const e: Y = { y: "y" }; // valid
const e: Y = { y: undefined }; // valid

function foo(x?: number): {}
foo() // valid
foo(4); // valid
foo(undefined) // invalid

function bar(x: number?): {}
bar(); // invalid
bar(4) // valid
bar(undefined) // valid

So the existing type { x?: string } in vanilla TS would be equivalent to { x?: string? } under the strict mode, which it sort of gets expanded out to anyway. In the strict mode, { x?: T } and { x: T? } coincide only when the value has the property x of type T.

Additionally I think the strict mode should do away with the unsound optional property weakening rule that says: { ... } is assignable to { ...; y?: string } if the former doesn’t have a conflicting y property. Instead the rules should be:

• { x: T } is assignable to { x?: T }.
• { ... } is assignable to { ...; y?: unknown }.

The reverse can be applied through in narrowing such that:

• If a : { x?: T } then "x" in a narrows to { x: T }.
• If a : object then "x" in a narrows to { x?: unknown }, or some suitable intersection type.

The strict mode could also have some interesting interactions with never. Right now a type { x: never } is sort-of meant to mean that x does not exist, though the type should really be isomorphic to never. The type { x?: never } says either the property does not exist, or it exists with type never, so only the former can be true. The type { [K in string | number | symbol]?: never } might represent the true empty object.

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.

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.

@Vanuan never | T is T. I get what you are trying to do, but unfortunately never is not meant to model this situation.

The crux of the problem, unfortunately, is that the type system can’t model this today; not that the syntax for it is overly verbose. @masonk hit the nail on the head in https://github.com/microsoft/TypeScript/issues/13195#issuecomment-269620662

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.

part of the problem here is that typescript’s interfaces are open. For instance (using a missing type to indicate optional key/value pairs, without implying undefined is a legal value):

interface Foo1 {
  bar: string | missing;
}

let f: Foo1 = {}; // valid
let g: {} = {bar: undefined}; // valid
f = g // should be an error, but {} is a valid Foo1

If we try to model Foo1 as {bar: string} | {} we have the problem that {} is short for "an interface with no fields, … or with arbitrary keys and values.

As for a path forward, I see two options: a) try to tackle this in combination with some sort of “closed” concept for interfaces, or for single keys on interfaces b) try to tackle this similarly to the “object literals don’t have excess properties” checks, which avoids the need for working this thoroughly into the algebra of the type system

in (a) we would want something like

interface Foo1 {
  bar: string | missing;
}

let f: Foo1 = {}; // valid
let g: {} = {bar: undefined}; // valid
f = g // Error: open interface {} isn't a valid Foo1 because it can have a bar
let h: BanKeys<{}, "bar"> = {bar: undefined}; // error: object has banned "bar" key
let i: BanKeys<{}, "bar"> = {}; // ok
i.bar = undefined; // error: i may not have "bar" key
f = i; // ok

An alternate version, using a special missing type for everything instead of BanKeys<> that I made up

interface Foo1 {
  bar: string | missing;
}

let f: Foo1 = {}; // valid
let g: {} = {bar: undefined}; // valid
f = g // Error: {} isn't a valid Foo1 because it can have a bar, and bar
let h: {bar: missing} = {bar: undefined}; // error: object has banned "bar" key
let i: {bar: missing} = {}; // ok
f = i; // ok
i.bar = undefined; // error: i may not have "bar" key

I’m less convinced by the general usefulness of option (b). There, we would get similar safety as option (a), but only on object literals passed directly to the libraries using missing in their type annotations. In practice I’d expect this would sometimes be useful, but probably not sufficient for most cases.

FYI a small extra example when it is needed.

It is a necessity when you are working with Firestore. Firestore doesn’t allow you to store undefined values and responds with error. Currently TS doesn’t catch an explicit undefined values you accidentally pass to Firestore. You usually can do it intentionally or using spread syntax on object.

For this particular case I have to handle that via autotests (I can mock firestore client and track that we never pass an explicit undefined value in tests). But that is not ideal (it is difficult to make a full tests coverage) and I would prefer TS to track that.

If I’m not mistaken, the importance of the distinction is most important for mapped types, e.g. for a patchObject() function.

But having ? cover undefined as is currently the case is also useful, e.g. for monomorphic object factories.

interface Foo<T> {
  bar: T,
  baz?: T
}
function makeFoo<T>(bar: T, baz?: T):Foo {
  return {bar, baz}
}

The former pattern is probably more common than code that requires making the distinction between missing and undefined. It is important because it lets JS engines optimize objects with a hidden class, whereas adding or deleting keys triggers slow code paths.

So the current semantics give nice ergonomics to a pattern that’s useful in practice.

So it would be nice to let users have it both ways. The | void suggestion above would be a possibility, but the presence of a key is part of the type of the object, and that syntax makes it look like it’s part of the type of the value. Hence my proposal in #26438 to introduce a ?! suffix that would introduce the semantics proposed here, and keep ? as it is now.

This would also be backwards compatible without the need of a “codemod” script to update every optional property.

@shmidt-i My understanding is that if you declare a variable of type Record<string, number>, then whatever property you will take from it, it should return a number. Your type UncertainShape is explicitly against that assumption that’s why it throws an error.

Here you can see a similar example. What is in my opinion misleading, is that second line is OK. I personally would prefer to get error in both situations.

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.

@tom-sherman You can do it if you constrain T to Array<any> since function arguments are a tuple that extends Array. See example below. You can probably also do it without the constraint by using conditional types or function overloads. It is a trade-off between cosmetic beauty and simplicity of the implementation.

type Result<T extends Array<any>, E> = {t: T}|{e: E}
function Ok<A extends Array<any>>(...t: A): Result<A, never> {
  return {t}
}

const foo: Result<[], Error> = Ok()
const bar: Result<[number], Error> = Ok(123)

@Vanuan never | T is T. I get what you are trying to do, but unfortunately never is not meant to model this situation.

Yeah, I wanted this: let o: { field: never } = { };. Apparently, this is invalid code. So there’s no way to model a type of an object which is guaranteed to not have a given key or no keys at all.

That is, there’s no difference between plain objects and duck-like objects.

Which means TypeScript is still inherently a duck-typed language.

So, the fix should include:

1. Treat optional field type as never | T instead of never | undefined.
2. Disallow assigning undefined to optional. That is undefined should not be assigned to never | T if T doesn’t include undefined
3. Disallow deleting fields that are non-optional. delete should only be allowed for fields of type that includes never and some other type. It should not be allowed to delete a field of type undefined.
4. Deleting optional field should work like type guards. That is, they should not change the type of a variable, that is you can still assign a value to it even if you deleted it. When you’re passing a value of the type to a function, it should be treated as type-guarded type, i.e. field: never | number should become field: number after delete a.field operation. But if you’re passing the reference to an object, of course its type shouldn’t change, because it doesn’t change in runtime.

It’s debatable what should happen when assigning an optional field to a new variable. Should the result type be never | T or never | T | undefined. We can’t really know which is it. If the field is optional and was not present it would be undefined in runtime. But this behavior should be an error usage of a field. So maybe it’s a warning? E.g. “please use type guard to ensure the property is present in the object”. Well, most functions don’t support never type as an argument, so maybe it doesn’t matter. You would need a type guard anyway.

@AnyhowStep that’s a really good point, it has two conflicting meanings right now. In f: We don’t care about the value, it could be anything In foo: The value is missing and evaluates as false

function doThingWithNum(n: number) {}

function foo(x: string, y: number | void, z: boolean | void) {
    if (y) {
        doThingWithNum(y); // works, but should error because we haven't actually proven it's a number
    }
}

foo("a", 1, true); foo("a", 1); foo("a"); // okay

const f: () => void = () => "i am a string";
foo("x", f());

Playground

@jcalz this seems like a really bad bug, especially if people are using void to mean missing.

What’s worse is there doesn’t seem to be a way to fix this without breaking backwards compatibility

@elektronik2k5 I would not recommend to do this particular thing on backend. Sometimes thrown error is better than saving [potentially] invalid data. Some value can be set to undefined accidentally (e.g. instead of null/0/""/false or hundreds of other reasons).

That’s why we love TS - once you covered your code with a good types you don’t need to take care of such things (write an extra programmatic layer for validation and/or autotests).

Probably(!) Firestore library contributors will be the first who apply this TS feature in their codebase. And I’m quite sure they intentionally do not suppress undefined values on their library side before saving.

Typescript version 3.3 strictNullChecks enabled:

type UncertainShape = {
    uncertainProp?: number;
    certainProp: number;
}

declare var a: UncertainShape;
var b: Record<string, number> = a; 
// here is error, since number | undefined cannot be assigned to number
// but should be okay since both variants of having and not having uncertainProp
// presented in the shape should still match the shape of Record<string, number>

not sure how we arrived at talking about arguments, but an arguments-less example:

function foo(...args: any[]){ return args.length; }
foo(); // returns 0
foo(undefined); //return 1

IMO that’s less ugly that using arguments directly, but it’ll transpile to arguments if your target is es5.

But anyhow this topic was originally about missing keys vs present keys with an undefined value within an object. That feels like a different case than missing vs. present arguments to functions - though if we can figure out a way to unify the two concepts in the type system I’m all for it.

@felixfbecker this is not how it currently works, Typescript will complain stating Expected 1 arguments, but got 0.

Also foo() and foo(undefined) are not exactly equivalent. Take the following example:

function foo () { return arguments.length; }
foo() // returns 0
foo(undefined) // returns 1

For arrow functions the semantics would be the same though since arguments is not accessible.

I’m on the fence about whether Typescript should function according to the exact semantics or not. It’s a bit of an edge case, and as far as I know use of arguments is not something Typescript makes an effort to account for anyway.

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