Type Assertion Helpers in TypeScript

TypeScript's type system is powerful, but sometimes the compiler can't infer the correct type. Type assertions allow you to tell the compiler you know more about a value's type than it does. This challenge asks you to implement helper functions that provide more robust and safer type assertion capabilities, addressing common scenarios and potential pitfalls.

Problem Description

You need to implement three helper functions in TypeScript: assertNonNull, assertNever, and assertType. These functions will provide safer and more expressive ways to perform type assertions compared to the standard as keyword. The goal is to reduce the risk of runtime errors caused by incorrect type assumptions and improve code clarity.

• assertNonNull<T>(value: T | null | undefined): T: This function asserts that a value is not null or undefined. If the value is null or undefined, it throws a TypeError with a descriptive message. Otherwise, it returns the value as type T. This is a safer alternative to value as T when dealing with potentially nullable/undefined values.

• assertNever(value: never): never: This function asserts that a value is of type never. Since never represents a value that never occurs, this function should throw a TypeError if it receives a value. This is useful for debugging and ensuring that code paths that should never be reached are properly handled.

• assertType<T, U>(value: T, type: new (...args: any[]) => U): U: This function asserts that a value is an instance of a specific constructor function (type). If the value is not an instance of the provided constructor, it throws a TypeError with a descriptive message. Otherwise, it returns the value as type U (which will be the same as T in most cases, but allows for more flexibility).

Examples

Example 1:

Input: assertNonNull<string>(null)
Output: TypeError: Expected a non-null and non-undefined value.
Explanation: The input is null, which violates the non-null/undefined assertion. A TypeError is thrown.

Example 2:

Input: assertNonNull<number>(123)
Output: 123
Explanation: The input is a number (not null or undefined), so it's returned as a number.

Example 3:

Input: assertNever(0 as never)
Output: TypeError: Expected a never value.
Explanation: The input is 0, which is not never. A TypeError is thrown.

Example 4:

Input: assertType<string, Date>(new Date(), Date)
Output: TypeError: Expected an instance of Date.
Explanation: The input is a Date object, but the assertion requires an instance of Date. A TypeError is thrown.

Example 5:

Input: assertType<string, String>("hello", String)
Output: "hello"
Explanation: The input is a string, and the assertion requires an instance of String.  The string is returned as a String.

Constraints

• All functions must throw a TypeError when the assertion fails.
• The error messages in the TypeError should be clear and descriptive.
• The functions should be type-safe and avoid unnecessary type conversions.
• The assertType function should handle constructor functions with any number of arguments.
• The assertType function should correctly identify instances of the specified constructor.

Notes

• Consider using instanceof operator within assertType to check if a value is an instance of a constructor.
• Think about how to provide informative error messages to aid in debugging.
• The assertNever function is primarily for debugging and should not be used in production code unless you have a very specific reason to do so. It's meant to catch unexpected code paths.
• The assertNonNull function is a common pattern for handling potentially nullable/undefined values. It's a safer alternative to simply casting with as.