"satisfies" operator to ensure an expression matches some type (feedback reset)

[RyanCavanaugh]

Feature Update - February 2022

This is a feedback reset for #7481 to get a fresh start and clarify where we are with this feature. I really thought this was going to be simpler, but it's turned out to be a bit of a rat's nest!

Let's start with what kind of scenarios we think need to be addressed.

Scenario Candidates

First, here's a review of scenarios I've collected from reading the linked issue and its many duplicates. Please post if you have other scenarios that seem relevant. I'll go into it later, but not all these scenarios can be satisfied at once for reasons that will hopefully become obvious.

Safe Upcast

Frequently in places where control flow analysis hits some limitation (hi #9998), it's desirable to "undo" the specificity of an initializer. A good example would be

let a = false;
upd();
if (a === true) {
//    ^^^ error, true and false have no overlap
    // ...
}
function upd() {
    if (someCondition) a = true;
}

The canonical recommendation is to type-assert the initializer:

let a = false as boolean;

but there's limited type safety here since you could accidently downcast without realizing it:

type Animal = { kind: "cat", meows: true } | { kind: "dog", barks: true };
let p = { kind: "cat" } as Animal; // Missing meows!
upd();
if (p.kind === "dog") {

} else {
    p.meows; // Reported 'true', actually 'undefined'
}
function upd() {
    if (Math.random() > 0.5) p = { kind: "dog", barks: true };
}

The safest workaround is to have a dummy function, function up<T>(arg: T): T:

let a = up<boolean>(true);

which is unfortunate due to having unnecessary runtime impact.

Instead, we would presumably write

let p = { kind: "cat", meows: true } satisfies Animal;

Property Name Constraining

We might want to make a lookup table where the property keys must come from some predefined subset, but not lose type information about what each property's value was:

type Keys = 'a' | 'b' | 'c' | 'd';

const p = {
    a: 0,
    b: "hello",
    x: 8 // Should error, 'x' isn't in 'Keys'
};

// Should be OK -- retain info that a is number and b is string
let a = p.a.toFixed();
let b = p.b.substr(1);
// Should error even though 'd' is in 'Keys'
let d = p.d;

There is no obvious workaround here today.

Instead, we would presumably write

const p = {
    a: 0,
    b: "hello",
    x: 8 // Should error, 'x' isn't in 'Keys'
} satisfies Partial<Record<Keys, unknown>>;
// using 'Partial' to indicate it's OK 'd' is missing

Property Name Fulfillment

Same as Property Name Constraining, except we might want to ensure that we get all of the keys:

type Keys = 'a' | 'b' | 'c' | 'd';

const p = {
    a: 0,
    b: "hello",
    c: true
    // Should error because 'd' is missing
};
// Should be OK
const t: boolean = p.c;

The closest available workaround is:

const dummy: Record<Keys, unknown> = p;

but this assignment a) has runtime impact and b) will not detect excess properties.

Instead, we would presumably write

const p = {
    a: 0,
    b: "hello",
    c: true
    // will error because 'd' is missing
} satisfies Record<Keys, unknown>;

Property Value Conformance

This is the flipside of Property Name Constraining - we might want to make sure that all property values in an object conform to some type, but still keep record of which keys are present:

type Facts = { [key: string]: boolean };
declare function checkTruths(x: Facts): void;
declare function checkM(x: { m: boolean }): void;
const x = {
    m: true
};

// Should be OK
checkTruths(x);
// Should be OK
fn(x);
// Should fail under --noIndexSignaturePropertyAccess
console.log(x.z);
// Should be OK under --noUncheckedIndexedAccess
const m: boolean = x.m;

// Should be 'm'
type M = keyof typeof x;

// Should be able to detect a failure here
const x2 = {
    m: true,
    s: "false"
};

Another example

export type Color = { r: number, g: number, b: number };

// All of these should be Colors, but I only use some of them here.
export const Palette = {
    white: { r: 255, g: 255, b: 255},
    black: { r: 0, g: 0, d: 0}, // <- oops! 'd' in place of 'b'
    blue: { r: 0, g: 0, b: 255 },
};

Here, we would presumably write

const Palette = {
    white: { r: 255, g: 255, b: 255},
    black: { r: 0, g: 0, d: 0}, // <- error is now detected
    blue: { r: 0, g: 0, b: 255 },
} satisfies Record<string, Color>;

Ensure Interface Implementation

We might want to leverage type inference, but still check that something conforms to an interface and use that interface to provide contextual typing:

type Movable = {
    move(distance: number): void;
};

const car = {
    start() { },
    move(d) {
        // d should be number
    },
    stop() { }
};

Here, we would presumably write

const car = {
    start() { },
    move(d) {
        // d: number
    },
    stop() { }
} satisfies Moveable;

Optional Member Conformance

We might want to initialize a value conforming to some weakly-typed interface:

type Point2d = { x: number, y: number };
// Undesirable behavior today with type annotation
const a: Partial<Point2d> = { x: 10 };
// Errors, but should be OK -- we know x is there
console.log(a.x.toFixed());
// OK, but should be an error -- we know y is missing
let p = a.y;

Optional Member Addition

Conversely, we might want to safely initialize a variable according to some type but retain information about the members which aren't present:

type Point2d = { x: number, y: number };
const a: Partial<Point2d> = { x: 10 };
// Should be OK
a.x.toFixed();
// Should be OK, y is present, just not initialized
a.y = 3;

Contextual Typing

TypeScript has a process called contextual typing in which expressions which would otherwise not have an inferrable type can get an inferred type from context:

//         a: implicit any
const f1 = a => { };

//                              a: string
const f2: (s: string) => void = a => { };

In all of the above scenarios, contextual typing would always be appropriate. For example, in Property Value Conformance

type Predicates = { [s: string]: (n: number) => boolean };

const p: Predicates = {
    isEven: n => n % 2 === 0,
    isOdd: n => n % 2 === 1
};

Contextually providing the n parameters a number type is clearly desirable. In most other places than parameters, the contextual typing of an expression is not directly observable except insofar as normally-disallowed assignments become allowable.

Desired Behavior Rundown

There are three plausible contenders for what to infer for the type of an e satisfies T expression:

• typeof e
• T
• T & typeof e

*SATA: Same As Type Annotation - const v = e satisfies T would do the same as const v: T = e, thus no additional value is provided

Scenario	T	typeof e	T & typeof e
Safe Upcast	✔	❌ (undoes the upcasting)	❌ (undoes the upcasting)
Property Name Constraining	❌ (SATA)	✔	✔
Property Name Fulfillment	❌ (SATA)	✔	✔
Ensure Interface Implementation	❌ (SATA)	✔	✔
Optional Member Conformance	❌ (SATA)	✔	❌ (members appear when not desired)
Optional Member Addition	❌ (SATA)	❌ (members do not appear when desired)	✔
Contextual Typing	✔	✔	✔

Discussion

Given the value of the other scenarios, I think safe upcast needs to be discarded. One could imagine other solutions to this problem, e.g. marking a particular variable as "volatile" such that narrowings no longer apply to it, or simply by having better side-effect tracking.

Excess Properties

A sidenote here on excess properties. Consider this case:

type Point = {
    x: number,
    y: number
};
const origin = {
    x: 0,
    y: 0,
    z: 0 // OK or error?
} satisifes Point;

Is z an excess property?

One argument says yes, because in other positions where that object literal was used where a Point was expected, it would be. Additionally, if we want to detect typos (as in the property name constraining scenario), then detecting excess properties is mandatory.

The other argument says no, because the point of excess property checks is to detect properties which are "lost" due to not having their presence captured by the type system, and the design of the satisfies operator is specifically for scenarios where the ultimate type of all properties is captured somewhere.

I think on balance, the "yes" argument is stronger. If we don't flag excess properties, then the property name constraining scenario can't be made to work at all. In places where excess properties are expected, e satisfies (T & Record<string, unknown>) can be written instead.

However, under this solution, producing the expression type T & typeof e becomes very undesirable:

type Point2d = { x: number, y: number };
const a = { x: 10, z: 0 } satisfies Partial<Point2d> & Record<string, unknown>;
// Arbitrary writes allowed (super bad)
a.blah = 10;

Side note: It's tempting to say that properties aren't excess if all of the satisfied type's properties are matched. I don't think this is satisfactory because it doesn't really clearly define what would happen with the asserted-to type is Partial, which is likely common:

type Keys = 'a' | 'b' | 'c';
// Property 'd' might be intentional excess *or* a typo of e.g. 'b'
const v = { a: 0, d: 0 } satisfies Partial<Record<Keys, number>>;

Producing typeof e then leads to another problem...

The Empty Array Problem

Under --strict (specifically strictNullChecks && noImplicitAny), empty arrays in positions where they can't be Evolving Arrays get the type never[]. This leads to some somewhat annoying behavior today:

let m = { value: [] };
// Error, can't assign 'number' to 'never'
m.value.push(3);

The satisfies operator might be thought to fix this:

type BoxOfArray<T> = { value: T[] };
let m = { value: [] } satisfies BoxOfArray<number>
// OK, right? I just said it was OK?
m.value.push(3);

However, under current semantics (including m: typeof e), this still doesn't work, because the type of the array is still never[].

It seems like this can be fixed with a targeted change to empty arrays, which I've prototyped at #47898. It's possible there are unintended downstream consequences of this (changes like this can often foul up generic inference in ways that aren't obvious), but it seems to be OK for now.

TL;DR

It seems like the best place we could land is:

• Contextually type empty arrays
• Disallow excess properties (unless you write T & Record<string, unknown>)
• Use typeof e as the expression type instead of T or T & typeof e

Does this seem right? What did I miss?

[magnushiie]

If you discard safe upcast you shouldn't probably close #7481 with the current issue as a solution as it was only about safe upcast which somehow morphed into discussion about something else. I totally see the value in the other scenarios, but it seems to be a different feature.

EDIT: now after some thinking I think you are right there are not many scenarios left where safe upcast is needed if satisfies existed.

[cefn]

Agree it should be typeof e for my expectations of the operator.

Can't we expect people to use as T[] to explicitly type empty arrays if they expect the compiler to help them. Using as in this case can have no runtime consequences at the point of assignment (not having any members which could incorrectly be inferred as type T). In your example it would be let m = { value: [] as number[] }. I find I have to do this once in a while.

I don't think the approach to satisfies is responsible for a situation which already allows drifts in array nature arising from push, not captured by the compiler, like this example even for non-empty arrays...

type Tuple = [number, number];
function tackOneOn(tuple: Tuple){
    tuple.push(4)
    return tuple;
}
const mutated: Tuple = [3,4] 
const returned = tackOneOn(mutated); // also Tuple, refers to mutated, but is 3 long
const howMany = returned.length // type 2

[ethanresnick]

I totally agree with discarding the safe upcast case in favor of the other scenarios.

As far as using typeof e vs typeof e & T as the type for e satisfies T... I think we definitely want to incorporate some information from T into the final type. Your example with the empty arrays shows this, but I think it also applies with the Ensure Interface Implementation example. I.e., in that example, we want the argument to move to be typed as a number, not any, so we can't 100% throw away the type information in Movable. I think that's what people were trying to accomplish by using typeof e & T.

What I don't really understand well enough is how exactly contextual typing comes into play here. Like, I think the contextual typing process could allow us to incorporate some information from the type T without literally creating an intersection type? If so, that seems like the way to go. But then couldn't that also handle the empty array case without any special treatment?

[RyanCavanaugh]

Contextual typing will set move's parameter to number; no additional mechanics are needed there.

The fact that parameters get their types from contextual typing but arrays don't is a sort of barely-observable difference (today) that this operator would make very obvious, hence the PR to change empty arrays.

[ethanresnick]

@RyanCavanaugh Thanks. Gotcha. That seems like a good change then, almost independent of what happens with satisfies.

[ethanresnick]

For excess property checking... I honestly have no idea. But I'm a bit confused about how z could be an excess property in:

 const origin = {
    x: 0,
    y: 0,
    z: 0 // OK or error?
} satisifes Point;

while start and stop would not be excess properties in:

const car = {
    start() { },
    move(d) {
        // d: number
    },
    stop() { }
} satisfies Moveable;

[cefn]

I wasn't expecting any Contextual Typing at all arising from satisfies and this was a surprise.

This would clutter my comprehension of the likely consequences of the operator. I was expecting satisfies to be an uncomplicated request for validation support (e.g. please check but don't type). Adding in expectations of Contextual Typing places it into a different category so I would have to do more work to reason about it.

Before reading this aspect of the proposal I expected to fulfil all the requirements of the type system when declaring or assigning (using the normal tools), but satisfies would let me ask the compiler 'did I get it right' for some well-defined validation.

[RyanCavanaugh]

This would clutter my comprehension of the likely consequences of the operator.

Consider this example:

const car = {
    start() { },
    move(d) {
        // d: number
    },
    stop() { }
} satisfies Moveable;

Without contextual typing, d would be an implicit any error, even though we know from the fact that you wrote satisfies Moveable that you want it to be number. Can you talk more about why that'd be desirable?

[ethanresnick]

This may come across as a bit of a non-sequitur, but, if we're thinking about excess property checking rules, it also seems like we should make sure that the ultimate design for satisfies can play well with IDE autocomplete and the "Rename Symbol" refactoring.

With satisfies, I think excess property checking's primary purpose would be to catch two kinds of potential mistakes: typos, and properties that accidentally get left with their old names after a refactor. However, autocomplete and "Rename Symbol" in the IDE can prevent the same mistakes — typos and legacy property names — that excess property checking is trying to catch!

Of course, editor assistance features can't fully replace excess property checks; each has clear strengths and limits. But I do think the same concerns that motivate checking for excess properties with satisfies (which isn't strictly necessary) would suggest making sure there can be good TS language server support too.

I'd hate to land on a design that somehow makes an automatic refactor like this hard to implement:

export type Color = { r: number, g: number, b: number };

export const Palette = {
    white: { r: 255, g: 255, b: 255},
    black: { r: 0, g: 0, b: 0},
    blue: { r: 0, g: 0, b: 255 },
} satisfies Record<string, Color>;

Here, I think I should be able to rename r -> red, g -> green and b -> blue in the Color type, using "Rename Symbol" in my IDE, and have that rename all the properties in the color objects in Palette. Also, if I start adding a new green key to Pallete, I think I should get autocomplete when writing the keys in the new object that I'm using as the value.

Perhaps it's roughly-equally easy to support that kind of IDE behavior for any of the designs we're considering here, in which case this really is orthogonal/can be ignored in this thread. But I'm just raising it because I have no idea how that language server stuff works.

[fatcerberus]

Up until recently I was in the "satisfies as safe upcast" camp, but I was just presented with an argument against it. Someone asked why this code didn't typecheck:

interface ApiResponseItem {
}

interface ApiResponse {
  [ index: string ]: string | number | boolean | ApiResponseItem | ApiResponseItem[]
}

let x : ApiResponse = {
  items: [ { id: 123 } ],
  bob: true,
  sam: 1, 
  sally: 'omg',
}

console.log(x);

class Test {
  private result : boolean | undefined;

  doIt () {
    let person : ApiResponse = {
      bob: true
    };
    this.result = person.bob;  // <-- error here
  }
}

Presumably the person who wrote this code wanted to ensure upfront that the object literal was a valid ApiResponse, but still expected TS to treat person.bob as boolean, as if there was no type annotation (they had worked around it with a cast to as boolean, which is very unsafe!). I had to explain that by including the type annotation, they were asking the compiler to forget about the actual contents of the object literal. If { ... } satisfies ApiResponse only affected contextual typing without acting as an upcast, it would be an elegant solution to this problem.

[dead-claudia]

@RyanCavanaugh I like the idea, but have you considered implements as the operator? (Though at the same time, it'd be worth verifying with TC39 whether that would run TS into trouble later.)

[cefn]

Hey, thanks @RyanCavanaugh for considering my feedback! Here’s some thoughts why Contextual Typing might not be desirable in my view.

DEFEATS PURPOSE

Assuming the intent that satisfies would validate typing, adding Contextual Typing might even somewhat defeat its purpose. Given the example you shared, I was expecting noImplicitAny to force me to be explicit about typing, with satisfies checking I got it right. I’d expect to be able to copy-paste the const car declaration somewhere else, knowing that I had satisfied Moveable.

const car = {
    start() { },
    move(d) {},
    stop() { }
} satisfies Moveable;

EXPLANATORY SIMPLICITY, LEAST SURPRISE

I want to guide colleague adopters of Typescript with simple statements about the behaviour of the language.

As per other comments in this thread, adopters often seem to think that ‘as X’ is a suitable workaround to ensure typing when it is normally exactly the opposite. It would be easy to guide them towards typing the structure with all the pre-existing tools then use satisfies if they want the compiler to help them with localised warnings. If satisfies doesn’t pass without errors, they’ve missed something and should fix it.

Explaining to them that satisfies does type-checking with no effect on types is helpfully simple and provides an answer to what they should do instead of as X. It means the author is still responsible to locally fulfil the type of everything in the normal way, and that satisfies does compile-time validation a bit like expect does build time assertion.

even though we know from the fact that you wrote satisfies Moveable that you want it to be number

To give an idea of how the Contextual Typing augmentation tripped me up, this was as if I told you that `expect(value).toBe(true) would actually set the value in some circumstances (because you said you expected that) !

Having this dual role makes it a different category of operator to my mind. Following the expect analogy it wouldn’t be easy to separate the ‘setup’ part from the ‘assert’ part of a test - they would be blended. You would have to step up your game to deal with its special cases and in my view, those socialising the language would find it harder to share.

OCKAM’S RASOR

When I have hit the ‘dead ends’ which required this operator, the feature which wasn’t available in any other way was a form of type-checking without typing for which no mechanism existed at all.

By contrast, blending in a Contextual Typing feature here isn’t driven by necessity, as all the typing you describe can be easily achieved in other ways (including existing Contextual Typing mechanisms). In the case you shared we would simply have to type d through any of the normal mechanisms.

const car = {
    start() { },
    move(d: number) {},
    stop() { }
} satisfies Moveable;

I speculate if this is more likely in any real case anyway and would explicitly benefit from the existing Contextual Typing feature

const car: Moveable & Service = {
    start() { },
    move(d) {},
    stop() { }
};

TYPE LOCALISATION PRACTICE

Maybe worth noting some community practice even tries to force types to be explicit when they can be inferred. So I believe some would see concrete benefit from seeing move(d: number) in codebases. Personally I don’t think explicit-function-return-type should be a default typescript eslint rule at all, but the community disagrees with me. It makes me less worried about the language requiring d to be typed even in the presence of satisfies.

SUMMARY

Based on a minimal model of what satisfies could do (it checks if something is satisfied) having it actually add types to d violates least surprise for me personally.

I accept that others may have a more nuanced model and won’t need the operator to be cleanly validating with no 'side effects'. Looking forward to seeing how the feature develops!