Proposal: Enchance typeguards to infer type based on the returned type

[Akindin]

🔍 Search Terms

else typeguard, typeguard properties

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• 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, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Allow explicitly specify the type of tested value based on the type of result.

📃 Motivating Example

This allows to break existing types into a user defined subtypes, for example for valid | invalid strings

function isValidEmail(value: string): value is ValidEmail otherwise InvalidEmail {
    return /^\S+@\S+\.\S+$/.test(value)
}

function updateEmail(email: ValidEmail) {
    // ...
}

function showEmailFormatError(email: InvalidEmail){
    // ...
}

let email = document.querySelector("#email").value;

if (isValidEmail(email)) {
    updateEmail(email);
} else { // infers the type from otherwise
    showEmailFormatError(email)
}

Getting a response type based on a status

interface InProcessResponse {
  abort: () => void;
}

interface SuccessResponse {
  data: unknown;
}

interface ErrorResponse {
  errorCode: number;
  errorMessage: string;
}

function getStatus(response: unknown): 
    "success" means SuccessResponse |
    "pending" means InProcessResponse | 
    "error" means ErrorResponse | 
    "unknown" means unknown {
    //...
    return true
}

const response = getSomething();

switch(getStatus(response)) {
    case "success":
        // infers SuccessResponse
        break;
    case "pending":
        // infers InProcessResponse
        break;
    case "error":
        // infers ErrorResponse
        break;
    case "unknown":
        // infers unknown
        break;
}

💻 Use Cases

1. What do you want to use this for?
   To ensure handling of special cases and validation.
2. What shortcomings exist with current approaches?
   Need of typecasting and boilerplate
3. What workarounds are you using in the meantime?Either you make multiple typeguards Playground or you cast types before using typeguard Playground

[jcalz]

Why does getStatus return true and not "success" etc?

otherwise: duplicate of else type guard suggessted at #15048,
means: duplicate of #31376 and/or #46650

[Akindin]

Thanks for mentioning the related issues, they seem reasonably close to what I propose

Why does getStatus return true and not "success" etc?
Oh sorry that was a stub