Infer non returning function to be returning `undefined`, not `void`

Search Terms

non returning, undefined instead of void, undefined or unknown instead of void

Suggestion

• Change return of non returning functions to undefined instead of void
• Accept unknown as a type of non returning functions
  examples:

const f = () => {} // this gets inferred as () => void

const f1 = (): undefined => {} // doesn't work
// error: A function whose declared type is neither 'void' nor 'any' must return a value.(2355)

const f2 = (): unknown => {} // same error

https://www.typescriptlang.org/play/#code/MYewdgzgLgBAZjAvDAFASiQPhgbwL4CwAUMaJLHAIxKpoBcMArmACYCmcAlmGy1rjEIkiZaPABMNdA2YBrMCADuYfvmJA

Motivations

void is an annoying type to deal with, has many inconsistencies and there's a ton of issues around it for its weird behavior like: #35850 , #35236 , #33420 ... etc
Non-returning functions actually return undefined which is a more predictable type to deal with and narrow disjunctions with and even use optional chaining with.

Use Cases

Many use cases appear while using promises where there's a need to catch an error but at the same time not deal with void

const f = () => {}
async (p: Promise<A>) => {
  const a = await p.catch(f);
  // do stuff with a whose type is now A | void
};

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code

Not sure if this might break some code or not but I think any code that dealt with void should work while dealing with undefined?

• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

Es werden keine Quelldateien oder Tests genannt. Beginne mit den Inferenzbeispielen und dem verknüpften TypeScript-Playground und untersuche anschließend, wie sich die Änderung von Funktionen ohne Rückgabewert von void zu undefined auf die Anwendungsfälle für Promises und Narrowing auswirkt. Als abgeschlossen würde ein geklärtes Typensystem-Design für das vorgeschlagene Verhalten von undefined und unknown gelten.