"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!

[kasperpeulen]

@RyanCavanaugh I'm not sure how you picture the following examples when you go with the contender typeof e:

const a = [1, 2] satisfies [number, number];
const b = [1, 2] satisfies [unknown, unknown];
const c = [1, 2] satisfies [unknown, 2];
const d = {a: 1, b: 2} satisfies {a: unknown, b: 2};

If you assign const e = [1,2], then typeof e would become number[], but I would hope that:

• typeof a is now safely "downcasted" to [number, number]
• typeof b is also [number, number].
• typeof c is [number, 2].
• typeof d is {a: number, b: 2}.

[btoo]

@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.)

Resurfacing #7481 (comment) here, though I believe my suggestion has been mentioned more in the past

[RyanCavanaugh]

@kasperpeulen good questions, and ones I should have put in the OP. Arrays contextually typed by a tuple type retain their tupleness, and numeric literals contextually typed by a union containing a matching numeric literal type retain their literal types, so these would behave exactly as hoped (assuming contextual typing is retained).

A neat trick for trying these out in existing syntax is to write

// Put the desired contextual type here
declare let ct: {a: unknown, b: 2}
// Initialize with assignment expression
const d = ct = {a: 1, b: 2};
// d: { a: number, b: 2}

Chained assignment is AFAIR the only place where you can capture the inferred type of a contextually-typed expression.

[kasperpeulen]

@RyanCavanaugh I have read the proposal a couple of times, and all makes sense to me, except this point:

Disallow excess properties (unless you write T & Record<string, unknown>)

One of your examples would also not work if you would disallow excess properties:

const car = {
  // TS2322: Type '{ start(): void; move(d: number): void; stop(): void; }' is not assignable to type 'Movable'.
  //   Object literal may only specify known properties, and 'start' does not exist in type 'Movable'.
  start() {},
  move(d) {
    // d: number
  },
  stop() {},
} satisfies Moveable;

There are two reason why disallowing excess properties doesn't feel right to me.

1. I see satisfies as the implements keyword of classes, but then for object literals.
   For classes, it is all right to write this:

class Car implements Movable {
  start() {}
  move(d: number) {
  }
  stop() {}
}

For both satisfies and implements, it means that the object must be at least "Moveable", but it can be more, it can be a subtype. Having extra properties is one of the most common ways of becoming a subtype of Moveable, and it would be strange to disallow that.

2. It is much more logical to disallow extra properties when using type annotations:

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

As even if car is a subtype of Moveable with extra properties. We can not use those extra properties, we can not even access them, so it is much more likely to be a typo:

// TS2339: Property 'start' does not exist on type 'Movable'.
car2.start();

However, when we only want to satisfy "Moveable", but also purposely wanting to be more than that, we can access those extra properties just fine:

// fine
car.start();

I think disallowing excess properties when using satisfies is more a linter kind of feature, than a typescript feature, as it is not really giving any extra compile time safety, even if you make a typo, it will error somewhere else, and if it doesn't, it won't break anything:

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

declare function foo(object: Record<Keys, number>);

// hey why do I get an error here, I thought b had a default, oh wait, I made a typo there
const bar = foo({...defaults, c: 1);

Also, you won't get autocompletion for d, so it is quite hard to make this typo with the current popular editors/IDE's.

[jekh]

Would it also be possible to use the proposed satisfies operator on function declarations? For example:

type DoubleNumberFn = (a: number) => number

function doubleNumber(num) {
  // both num and doubled are numbers instead of any
  const doubled = num * 2

  // TS2322 Type 'string' is not assignable to type 'number'.
  return doubled.toString()
} satisfies DoubleNumberFn

This would potentially address the feature request in #22063

[ackvf]

My usecase is fairly simple.

Consider this possibly dangerous situation:

By using as I get hints (which is what I wanted), but it is dangerous as I get no type safety - no warnings for missing or extra unknown keys.

My ideal solution would be using is.

getFirebaseRef().push({} is MyItem)

-> now I would get hints for object properties
-> now I would get errors for missing and unknown properties

Which is practically equivalent to this:

const x: MyItem = { // Type '{}' is missing the following properties from type 'MyItem': another, id, param
  hi: 1, // Type '{ hi: number; }' is not assignable to type 'MyItem'. Object literal may only specify...
}
getFirebaseRef().push(x)

from #7481 (comment)

[peabnuts123]

+1 to the sentiments repeated several times already that a satisfies operator (or alternatively is or implements etc.) should be mostly used for type checking and not for inferring types. To put this in terms stated by the original post, I think that T as the result type is what most people desire. I comment here to say that the first scenario cannot be moved out-of-scope, as I believe it is the primary desire among people in the community, and the reason for the original thread (#7481).

To that end, I think that many of the scenarios in the OP are off-topic. The original summary explicitly states that basically all scenarios for a T result could be satisfied with a type annotation e.g.

const a: Movable = { … };
// is the same as
const a = { … } satisfies Movable;

I think this is exactly right. There is no type operator or keyword that is equivalent to this and I think that's what is missing. The motivation for a satisfies operator is for scenarios in which you cannot reasonably (or do not want to) declare a variable, and for that reason I think many of the examples given in the OP are not relevant. I don't think a satisfies operator is useful for the scenario in which you are simply declaring a variable. I do agree that there are several other separate issues described in the OP but I don't think they are in the scope for such a satisfies operator. We may possibly be able to hit multiple birds with a stone here, but as far as I can see it, the first example is the primary use-case.

Let me provide some further examples, similar to what others have posted already:

interface Component {
  id: string;
  name: string;
  // … other properties
}
// GOAL: Have a master list of all our components and some associated info/config/whatever
//  Secondary goal: don't allow extra properties. I personally think it is a source of bugs.

// Attempt A: Index signature type annotation.
// Result: UNDESIRED. No type safety for accessing properties on `componentsA`
const componentsA: { [index: string]: Component } = {
  WebServer: { id: '0', name: "Web Server" },
  LoadBalancer: { id: '1', name: "Load Balancer" },
  Database: { id: '1', name: "Load Balancer", url: "https://google.com" }, // DESIRED type error. `url` is extra
};
console.log(componentsA.NotARealComponent); // UNDESIRED because no type error. `componentsA` allows dereferencing any property on it

// Attempt B: Using `as` operator
// Result: UNDESIRED. Missing or extraneous properties on components
const componentsB = {
  WebServer: { id: '0', name: "WebServer" } as Component,
  LoadBalancer: { id: '1' } as Component, // UNDESIRED because completely missing property `name` (NO IDEA why this compiles at-present)
  Database: { id: '1', name: "Load Balancer", url: "https://google.com" } as Component, // UNDESIRED because no type error for extraneous `url` property
};
console.log(componentsB.NotARealComponent); // DESIRED type error. No property `NotARealComponent`
console.log(componentsB.LoadBalancer.name); // UNDESIRED because `name` property does not even exist on `LoadBalancer`

// Attempt C: Using a Type<T>() function
// Result: DESIRED. But there is no way of doing this with the type system - must invoke runtime identity function
function Type<T>(obj: T): T { return obj; }
const componentsC = {
  WebServer: Type<Component>({ id: '0', name: "WebServer" }),
  LoadBalancer: Type<Component>({ id: '1' }), // DESIRED type error. Property `name` is missing.
  Database: Type<Component>({ id: '1', name: "Load Balancer", url: "https://google.com" }), // DESIRED type error. Property `url` is extra.
};
console.log(componentsC.NotARealComponent); // DESIRED type error. No property `NotARealComponent`

I desire an operator that is the equivalent of the Type<T>() function as above, and I believe many others do too. There are other examples where this comes up too, such as passing an object to a function:

// Common interface
interface ComponentQuery {
  name: string;
}
// For querying for databases specifically
interface DbComponentQuery extends ComponentQuery {
  type: "db";
  shardId: string;
}
// etc… presumably other specific queries too

// Query for a component or something, IDK.
// Would return a `Component` in the real world.
// Just a contrived example.
function queryForComponent(component: ComponentQuery): void { /* … */ }

// GOAL: Call `queryForComponent()` for a DB component

// Attempt A: No type casting
queryForComponent({
  type: "db", // UNDESIRED because type error that `type` does not exist on `ComponentQuery`
  name: "WebServer",
  shardId: "2",
});

// Attempt B: `as` keyword
queryForComponent({
  type: "db",
  name: "WebServer",
  // UNDESIRED: Missing `shardId` property - not at all useful
} as DbComponentQuery);

// Attempt C: Type<T>() function
function Type<T>(obj: T): T { return obj; }
// DESIRED. Will not work if any property is missing, extra, or incorrect type.
queryForComponent(Type<DbComponentQuery>({
  type: "db",
  name: "WebServer",
  shardId: "2",
}));

// Only working alternative. Declare variable just to pass into function.
// Not always possible in certain difficult scenarios.
const query: DbComponentQuery = {
  type: "db",
  name: "WebServer",
  shardId: "2",
};
queryForComponent(query);

Apologies for the long and rather in-depth examples. I hope they will be useful to clarify the need here, and allow others to simply +1 this instead of needing to provide further similar examples.

I understand that all the scenarios described in the OP are real problems faced by people, and may or may not need addressing, but I believe the behavior I have described here is desired by many, and I feel that the OP and the conversation within this thread are explicitly heading towards removing it from the scope. Even if this satisfies keyword is to fulfill all the scenarios except this one, then the other issue needs to be left open and not related to this one.

Lastly I will say, if your desires are described in this comment, I would ask you to 👍 it. It will help keep the thread tidy while also demonstrating how much the community desires this behavior.

[ethanresnick]

@peabnuts123 You say "T as the result type is what most people desire", but (politely) what's the evidence for that? By my read, the original thread (asking for safe upcast) turned into a discussion of all these other use cases because those use cases are actually more common/powerful.

I think your examples actually show why limiting satisfies to a safe upcast is not ideal: both of your examples can pretty easily be handled by a version of satisfies that returns typeof e with contextual typing, whereas handling the other use cases with simply a safe upcast is not possible. To demonstrate:

// This has all the same safety as your componentsC example,
// modulo some open questions about excess property checks. And it has less repetition. 
const componentsC = {
  WebServer: { id: '0', name: "WebServer" },
  LoadBalancer: { id: '1' } // satisfies rejects this for missing the name
  Database: { id: '1', name: "Load Balancer", url: "https://google.com" }, // might or might not reject the extra url
} satisfies Record<string, Component>;

// Again, same safety as your example, except for the open questions about excess property checks.
queryForComponent({
  type: "db",
  name: "WebServer",
  shardId: "2",
} satisfies DbComponentQuery);

I also wanna point out that the TS team realized that e satisfies T as T might be a way to do a safe upcast, even if satisfies returns typeof e. If so, I think there's really very little reason to limit satisfies by having it return typeof e.

[peabnuts123]

@ethanresnick Thanks for responding to my examples and showing how the proposed logic could work to achieve those goals. I think you're right to put aside concerns around extraneous properties at this point too, as I get the sense that the community is divided on this matter. I included those concerns as relevant in my examples but I am happy to put them aside; I will say however that before anything like this lands in TypeScript, those concerns around extraneous properties need to be addressed and an informed decision made.

As for what evidence I have for my assumption, it seems clear to me that almost everybody in the original thread is asking for it. I have been following it for a while and perhaps in the middle of the thread the topic changes, but for example, from the first 10-20 replies there are many examples describing exactly the same thing, which to me appears to be out-of-scope for the proposal in this thread. Perhaps I am missing some nuance? I only know of up/down casting from strongly typed languages like Java and C# where an upcast is always safe and a downcast may lead to a runtime exception. TypeScript's semantics around upcasts and downcasts (might be missing properties) are somewhat mysterious to me (see "I don't know why this even compiles" comment in my previous example).

For clarity, my assumption is that most people seem to desire an operator essentially equivalent to:

function Is<T>(obj: T): T { return obj; }

I have realised that not explicitly passing <T> can lead to similar odd scenarios as the as operator, so I treat this proposed functionality as equivalent to always using the function like

const myThing = Is<Thing>({
  a: 2,
  b: 3,
});

where <Thing> is explicitly passed ALWAYS. Apologies for leaving that out of my previous post, I hadn't considered the danger of calling the function without it.

Here are examples of what I see as people asking for this functionality:

• The OP explicitly lays out this same function definition as the desired behaviour and gives several examples almost identical to my own, stating the function is the desired behaviour then later says explicitly that the desired result type is T not typeof e
• This person gives several examples explicitly stating that is A should result in type A and has received 48 +1 reacts
• This person demonstrates that declaring a temporary variable of type T gives the desired behaviour but they'd like to just pass it in directly and then writes exactly the same function as OP specifying <T> explicitly
• This person has posted above in this thread too stating that they'd like to specify the type of an object being passed to a function but cannot at-present
• "…I don't see scenarios when I don't want the type to be T."
• Another reference to writing an identity function for type checking
• Another example of trying to declare the type of an object in a place that variables cannot be reasonably declared

I feel personally that the use of such an operator in your first counter-example (satisfies Record<string, Component>) is undesirable. The suggested semantics do seem to work (aside from "extra" properties - a personal taste) for my examples but don't match my own internal semantics of the code I'm writing. Perhaps that is the difference in opinions here; indeed I can even see in the original thread @RyanCavanaugh early-on already proposing that the result type be typeof e or similar and people disagreeing. I don't think of this type check as forming around my entire object and then just returning whatever type is declared - I think of the type check as declaring the type i.e. the source of truth for what the type is (and expecting the compiler to enforce that). So declaring my whole object as a Record<string, Component> has IMO the side-effect of implying Component for each property (and then returning a "totally different" type), but I don't think of my master-list object as a Record<string, Component> nor am I even upcasting it to one.

Again I'd like to restate that I may be missing some nuance here as creating language and type systems is Hard™ so please forgive me if I'm missing the mark.

[orta]

Probably worth keeping in mind that people will probably ask for something like module.export satisfies XYZ (#38511) building on this, which would be well used in the modern web ecosystem.

[RyanCavanaugh]

In a world where satisfies returns the expression type:

• If you want to "safe upcast", write e satisfies T as T
• If you want any of the other scenarios listed here, you write e satisfies T

In a world where satisfies returns the asserted type:

• If you want to "safe upcast", write e satisfies T
• If you want any of the other scenarios listed here, you can't

One could make an argument that this means we need two operators, which, fine, but if you add satisfies as asserted-type, then you definitely need two operators and haven't solved most of the original use cases, whereas if you add satisfies as expression type, you've solved all the use cases via one syntax or another, and the second operator is just sugar for satisfies T as T

We also have to consider the relative frequency of things; if you have

const v: C = e;

or

function fn<T extends U>(arg: T): void;
fn<C>(e);

then you already have a place to write C that performs a safe upcast. There are certainly places you can't, or can't as easily, but it's definitely possible "a lot of the time" today. There are no syntactic positions today that behave like e satsifies T where that expression returns typeof e.

[BenjaBobs]

I like the idea of having the strictness and the "castness" be orthogonal.
This way the intent can be quite clear.

For example, if we imagine the satisfies and is keywords from previous discussions, and use strict (or maybe another word) to modify the strictness like so:

	Loose	Strict
Without cast	satisfies T	strict satisfies T
With cast	is T	strict is T

Given a type like this

type T = {
	a: number;
    b: bool;
}

I would expect the following behaviour:

Loose without cast

// typeof data === { a: number, b: bool, c: string }
const data = {
	a: 1, // OK, gets auto complete
	b: true, // OK, gets auto complete
    c: "text", // OK
} satisfies T;

// Error: missing property 'a' of 'T'
const data = {
	b: true, // OK, gets auto complete
} satisfies T;

Strict without cast

// Error: 'T' doesn't have property 'c'
const data = {
	a: 1, // OK, gets auto complete
	b: true, // OK, gets auto complete
    c: "text", // Bad
} strict satisfies T;

// Error: missing property 'a' of 'T'
const data = {
	b: true, // OK, gets auto complete
} strict satisfies T;

// typeof data === { a: number, b: bool }
const data = {
    a: 1, // OK, gets auto complete
    b: true, // OK, gets auto complete
} strict satisfies T;

Loose with cast

// typeof data === T
const data = {
	a: 1, // OK, gets auto complete
	b: true, // OK, gets auto complete
    c: "text", // OK
} is T;

// Error: missing property 'a' of 'T'
const data = {
	b: true, // OK, gets auto complete
} is T;

Strict with cast

// Error: 'T' doesn't have property 'c'
const data = {
	a: 1, // OK, gets auto complete
	b: true, // OK, gets auto complete
    c: "text", // Bad
} strict is T;

// Error: missing property 'a' of 'T'
const data = {
	b: true, // OK, gets auto complete
} strict is T;

// typeof data === T
const data = {
    a: 1, // OK, gets auto complete
    b: true, // OK, gets auto complete
} strict is T;

I know that this adds a lot of extra word reservation, and I'm not sure if that's against the wishes of the language design, but I think it conveys intent very clearly.

[somebody1234]

@ftonato (cc @josh-hemphill) note that you can forcibly narrow to a tuple by doing satisfies [] | User[] - the [] there forces typescript to narrow the type to a tuple, just in case it does turn out to be assignable

[BribeFromTheHive]

This would be a great feature to have.

Mechanically-speaking, it should enforce the same behavior as the below:

const something: SomeType = {...} //this object must conform to SomeType

function foo(param: SomeType) {}
foo({...}) //the passed object must conform to SomeType

function bar(): SomeType {
    return {...} //the returned object must conform to SomeType
}

Typescript is already quite powerful with type-casting, but aside from the above options, has a hard time with type enforcing.

const something = {...} as SomeType //often fails due to typecasting
const somethingElse = <SomeType>{...} //same problem as with the above

In many cases, these approaches require additional boilerplate code, making them cumbersome and less ergonomic for single-use or inline situations.

Therefore, as this request already proposes, having a loose, "on the fly" type assertion is the way to go:

export default {...} satisfies SomeType
//or
export default {...} is SomeType //retains the same keyword already enforced within typeguard function return value enforcement.

Introducing a more concise way to enforce types would make TypeScript more developer-friendly and allow for more ergonomic solutions in cases where existing methods are too verbose.

[RyanCavanaugh]

This would be a great feature to have.

Great news for you

[BribeFromTheHive]

Funny that it does exist, when I couldn't find the root of it based on this issue, couldn't find any search engine results, and neither ChatGPT nor Bing had any info on it (obviously it's quite a new fix). So thank you for sharing!