As a workaround while we don't get this implemented as a TS rule, we can do the following to ensure we both always return a value and also did not miss any case in the switch statement , without having to disable array-callback-return or no-unreachable:

const exhaustivenessSafetyCheck = (never: never) => {
  throw new Error(`Unknown value ${never}`)
}

// Example usage

const type: 'A' | 'B'

...

 switch (type) {
  case 'A':
    return ...
  case 'B':
    return ...
  default:
    return exhaustivenessSafetyCheck(type)
  }

This only accepts never as a type (triggering type errors if you pass anything else) and throws an error when called. If we forget to check one case in the switch, TS will complain that the argument passed to this function is not of type never

I think we could close this as being better handled by TS's noImplicitReturns option. (playground link with this enabled)

AFAICT the only case it doesn't cover is when there is no return statement at all (as opposed to some branches that don't have a return statement). But in TS this isn't a big deal, since the returned type will have void, which you can't do anything with.

@typescript-eslint/triage-team ?

To elaborate, noImplicitReturns essentially solves .map(), .reduce(), and friends.

TS itself solves .sort() and friends (by requiring a number to be returned)

And #10106 will solve .some()/.every() and .find() and friends.

So I don't see much remaining area of applicability for an extension rule, that's not already addressed somewhere else.

Agreed that this is yet another case of a core ESLint rule that is made unnecessary by TypeScript. Hooray, noImplicitReturns!