Optional chaining not working with void type

[overshom]

Demo

playground demo

TypeScript source with nightly version 3.8.0-dev.20191224

type Address = {
 city: string
}

type User = {
 home: Address | undefined
 work: Address | void
}

declare let u: User

u.home?.city
u.work?.city

JavaScript output the same for both "work" and "home" properties

"use strict";
var _a, _b;
(_a = u.work) === null || _a === void 0 ? void 0 : _a.city;
(_b = u.home) === null || _b === void 0 ? void 0 : _b.city;

Bug

If you run the code above, you will see that for u.home?.city there are no errors.
But for u.work?.city there is an error:

Error: Property 'city' does not exist on type 'void | Address'

Expectation

Optional chaining works for both 'undefined' and 'void' types the same way.

[MartinJohns]

Please follow the issue template for bugs. Here you would have to fill out terms you searched for to find existing issues.

Duplicate of #35236.

[DanielRosenwasser]

void is meant to be treated as an opaque return type for functions, since the type system allows you to assign () => number to a () => void.

In other words, it signals not just "this function doesn't return anything", but also "this functions values are not meant to be witnessed".

[overshom]

I believe my issue not about void itself. We could leave void definition the same as now.
It's about optional chaining doesn't skip empty types in union type.

Not working, but expected to work:

type Address = {
 city: string
}

declare let value: Address | void | null | undefined | never

value?.city

Working good:

declare let value: Address | null | undefined | never

value?.city

Why void breaks optional chaining - not clear for me still.
What stops us from adding support for optional chaining with void in union type - not clear.

[MartinJohns]

I believe my issue not about void itself.

Your issue is about your type being potentially void. Please check the other issue I linked you, the one you duplicated. Ryan provided reasoning there.

[overshom]

ok, I will try to find out my root issue.

Originally, my type was Address | undefined.
For some unknown yet reason undefined type getting lost through layers of generics and type inference.
Therefore, in output I've got just Address instead of Address | undefined.

Once I replaced undefined with void my output got much stronger and void not lost.
So, output became expected Address | void.

And then, I found that I cannot use optional chaining with void as undefined.

[Raiondesu]

Actually, this is a big issue for functions with optional contexts.

Currently, the only way to make a function that accepts an optional context is to define it as
this: SomeType | void, since this?: SomeType doesn't work.

Due to this issue, it's currently impossible to use optional chaining inside the function to access properties of such context:

type Foo = { bar?: { baz: string; }; };

function example(this: Foo | void, value: string) {
 return this?.bar?.baz ?? value; // Currently an error here
}

example('default string');

One could argue that this is solvable by using undefined instead of void, but this forces all invocations to provide the context of undefined:

type Foo = { bar?: { baz: string; }; };

function example(this: Foo | undefined, value: string) {
 return this?.bar?.baz ?? value; // No error, cool
}

example('default string'); // "The 'this' context of type 'void' is not assignable to method's 'this' of type 'Foo | undefined'." 😕

---

So, currently, optional chaining is broken completely for functions with optional contexts. See more examples in this playground.

---

I, personally, have many uses for functions like this in my libraries and projects. And I believe other people have use-cases too.

[johan-gorter]

I think this is a simple example showing that unions with void are actually helping prevent runtime problems:

function simpleCallback() { }

async function advancedCallback() {
 await Promise.resolve();
}

// registerCallback can be called using simpleCallback or advancedCallback for example
function registerCallback(callback: () => Promise<any> | void) {
 // Does not compile unfortunately:
 // callback()?.catch(console.error);
 
 // workaround without optional chaining
 let result = callback();
 if (result) {
 result.catch(console.error)
 }
}

[MartinJohns]

Johan Gorter (@johan-gorter) I think you should rather show why void should be part of the union type, and not undefined.

void in TypeScript means the absence of a type, not the absence of a value. There might be a value, but it shouldn't be used. If a value is present your check might even produce false-positive.

http://www.typescriptlang.org/docs/handbook/basic-types.html#void

void is a little like the opposite of any: the absence of having any type at all.

https://github.com/microsoft/TypeScript/wiki/FAQ#why-are-functions-returning-non-void-assignable-to-function-returning-void

Another way to think of this is that a void-returning callback type says "I'm not going to look at your return value, if one exists".

See also this comment by Ryan Cavanaugh (@RyanCavanaugh):

the problem with assuming a void-returning function is going to return a falsy value is that this code is legal:

var x: () => void = () => true;
if (x() || somethingImportant()) {
 // ...
}

[Raiondesu]

Martin Johns (@MartinJohns), there's no arguing that void shouldn't be a part of a union type that defines a value.

But there is a case I mentioned earlier in which there's no way for void not to be a part of such a type, as it just breaks typescript altogether.

In Johan Gorter (@johan-gorter)'s example, the void type can be easily replaced with undefined - voilà, the problem is solved, optional chaining works:

function simpleCallback(): undefined { return; }

async function advancedCallback() {
 await Promise.resolve();
}

// registerCallback can be called using simpleCallback or advancedCallback for example
function registerCallback(callback: () => Promise<any> | undefined) {
 // EZ
 callback()?.catch(console.error);
}

---

However, in the case of void being the part of a union type for a function context (this) - it's impossible to just remove the void or replace it with undefined.

[MartinJohns]

Alexey Iskhakov (@Raiondesu) You definitely brought up a valid case for void as part of the union type, but I think optional chaining support for void is the wrong approach to solve this (for the issues mentioned already).

void doesn't mean there is no context, it means there's no type information for the context - but it might very well be present and truthy and screw over optional chaining. So even if they'd allow ?. on union types involving void, they couldn't narrow the type and would have to fall back on any (or add another unsoundness to the type system).

To slightly adjust your example:

// `bar` is not optional anymore.
type Foo = { bar: { baz: string; }; };

function example(this: Foo | void, value: string) {
 // Only use optional chaining for `this`:
 return this?.bar.baz ?? value;
}

this might be truthy, but not match the Foo type, and accessing bar would cause a runtime error.

---

To solve your issue it would be better to allow to omit the context argument when the type is undefined.

type Foo = { bar?: { baz: string; }; };
function example(this: Foo | undefined, value: string) { return this?.bar?.baz ?? value; }

// Make this legal!
example('default string');

Or alternatively accept that the caller has to pass along undefined.

[Raiondesu]

I now clearly see the problem with this. I do agree with you.

But I still don't see how the context could just "suddenly" be different from the expected one (assuming we run code in 'use strict' mode).
I mean, unless the user explicitly sets the context using call, bind or apply, the context is undefined by-default. This means that TypeScript would intervene whenever the user changes context to the one that doesn't match the type.

And, also, if (this) still works, so this doesn't really add up with the "this might be truthy" argument. Why is optional chaining outlawed in this case, but a simple if type-guard is not?

type Foo = { bar?: { baz: string; }; };

function example(this: Foo | void, value: string) {
 if (!this) {
 return value;
 }

 // TS doesn't complain here!
 return this.bar?.baz;
}

example('default string');

If what you're implying is indeed true, and void represents that "no type information" is given - then we should've also outlawed if (this) here along with optional chaining on this (which would break the backward compatibility). Or... we could just allow optional chaining, as it is just a shortcut for if (this), is it not?

---

To solve your issue it would be better to allow to omit the context argument when the type is undefined.

Should I create a separate issue then?

[RyanCavanaugh]

This is not an intended use of void and you should never, ever on purpose write something like Foo | void in an input position. Any time you're tempted to write void like that, use unknown, never, or undefined depending on what you mean.

[Raiondesu]

I get it, Ryan Cavanaugh (@RyanCavanaugh), thanks, but how to deal with the function's context then?
It can't be never, undefined nor unknown. All three break the valid JS code of just calling the function afterwards without specifying the context.
Here are the examples in playground.

All examples listed are broken in some way or another. Even though two of them (void and undefined) are absolutely correct for the circumstance (in my opinion), TS doesn't allow any. Doesn't this mean that at least one of those types is broken in some way?