TypeScript Never Type Utilities

This challenge focuses on understanding and effectively utilizing TypeScript's never type. You will create utility types that leverage never to achieve precise type manipulation, particularly for scenarios where a value should logically be impossible or unrepresentable. This is crucial for building robust and type-safe code that prevents runtime errors by catching impossible states at compile time.

Problem Description

The never type in TypeScript represents values that will never occur. It's often used for functions that throw errors or have an infinite loop, or for exhaustive checks where all possible cases have been handled, and any remaining case is considered an error.

Your task is to create a set of utility types that demonstrate practical applications of the never type. These utilities should help in scenarios where you want to explicitly denote or enforce "impossible" states within your type system.

Key Requirements:

1. IsNever<T>: A type that resolves to true if T is never, and false otherwise.
2. AssertNever<T>: A type that, when given a type T, will cause a compile-time error if T is not never. If T is never, it should resolve to never without an error. This is useful for asserting that a particular branch of logic should be unreachable.
3. ExcludeNever<T>: A type that filters out any never types from a union type T. For example, if T is string | number | never, ExcludeNever<T> should resolve to string | number.

Expected Behavior:

• The utility types should behave as described above for various input types, including primitives, unions, intersections, and never itself.
• Compile-time errors should be produced where expected by AssertNever.

Edge Cases:

• Consider how your types handle unknown and any. While never is assignable to all types, the reverse is not true.
• How do your utilities behave with complex union types?

Examples

Example 1: IsNever<T>

type Test1 = IsNever<never>; // Expected: true
type Test2 = IsNever<string>; // Expected: false
type Test3 = IsNever<any>;    // Expected: false
type Test4 = IsNever<unknown>;// Expected: false
type Test5 = IsNever<null>;   // Expected: false
type Test6 = IsNever<undefined>; // Expected: false

Example 2: AssertNever<T>

function handleValue(value: string | number) {
    if (typeof value === 'string') {
        console.log("It's a string!");
    } else {
        // If we've handled all expected types, the remaining 'else' block
        // should ideally never be reached for a specific type.
        // Here, we expect 'value' to be 'number' in this 'else'.
        // If we were to add 'boolean' to the union later, this assertion
        // would catch the fact that 'number' is no longer 'never'.
        const impossible: AssertNever<typeof value> = value;
        // If 'value' is 'number', AssertNever<number> will produce a type error.
        // If 'value' were truly 'never', no error would occur.
    }
}

// This would cause a compile-time error:
// const errorTest: AssertNever<string> = "hello";

Example 3: ExcludeNever<T>

type Union1 = string | number | never;
type Result1 = ExcludeNever<Union1>; // Expected: string | number

type Union2 = never | boolean | undefined;
type Result2 = ExcludeNever<Union2>; // Expected: boolean | undefined

type Union3 = string | number;
type Result3 = ExcludeNever<Union3>; // Expected: string | number

type Union4 = never;
type Result4 = ExcludeNever<Union4>; // Expected: never

Constraints

• All utility types must be defined in TypeScript.
• Solutions should strive for maximal type safety and compile-time correctness.
• Performance of the type checking itself is not a primary concern, but avoid overly complex recursive types that might lead to extreme compilation times in very large projects.

Notes

• Think about how you can use conditional types (T extends U ? X : Y) to implement these utilities.
• The never type is assignable to any other type. How does this affect your implementations, especially for IsNever?
• Consider using [value: T] or (value: T) => void within a conditional type to distinguish between never and other types.
• The goal is to create types that fail compilation when an impossible condition is met, thereby guiding developers towards correct logic.