In TypeScript sometimes we need the as type operator to massage something which we know is allowed by the runtime, but the type system is not engineered to handle. This operator is inherently dangerous and will upcast any type to any other type as long as it has some properties in common. I’m proposing adoption of the satisfies U as T pattern to alleviate some of this danger.

An example of a situation in which you might need as is a method like Set.prototype.has, which should accept covariant parameters, but is not expressed in the type system:

declare const set: Set<string>;
declare const id: number | string;
// Argument of type 'string | number' is not assignable to parameter of type 'string'.
// Type 'number' is not assignable to type 'string'.ts(2345)
const has = set.has(id);

Ehh, ok? Of course, string | number is not assignable to string but this lookup is totally reasonable. There’s a few options to resolve the error and many of them are not really good. One option is to cast id using the as operator: set.has(id as string) but that has safety issues:

declare const set: Set<string>;
declare const id: { length: number };
// TypeScript thinks this is fine
const has = set.has(id as string);

You might also run into issues where a package author has defined the incorrect types for their package. This is especially common if you make use of the readonly modifier, or use very generic types like PromiseLike<T> instead of Promise<T>:

// This is pure function defined by an npm package that will be annoying
// to modify
declare const accumulate: (list: number[]) => number;
// This is our array which is defined as readonly to prevent modification
declare const values: readonly number[];
// Argument of type 'readonly number[]' is not assignable to parameter of type 'number[]'.
// The type 'readonly number[]' is 'readonly' and cannot be assigned to the mutable type 'number[]'.ts(2345)
accumulate(values);

Again, you can work around it with the as operator but the danger is still apparent:

declare const sum: (list: number[]) => number;
declare const values: readonly number[];
// Sure, ok
sum(values as number[]);
declare const objects: { toString: () => string }[];
// Wait, this is wrong
sum(objects as number[]);

TypeScript 4.9 introduced the satisfies operator which asserts that a given type “satisfies” this given constraint without changing the type. If we combine the two operators the result is a “safe upcast” operation. This was proposed by Ryan Cavanaugh in the original GitHub discussion on the operator.

declare const sum: (list: number[]) => number;
declare const values: readonly number[];
// Ok.
sum(values satisfies readonly number[] as number[]);
declare const objects: { toString: () => string }[];
// Raises an error!
sum(objects satisfies readonly number[] as number[]);

The syntax is verbose but serves the purpose of “burning in” the expected “in” type and the expected “out” type. The result is software which is more sound and resilient to refactors.