[isolatedDeclarations] explicit annotation required when `satisfies T` is provided on an object that would otherwise be inferrable

[bradzacher]

🔎 Search Terms

isolatedDeclarations, "as const", "satisfies"

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ

⏯ Playground Link

https://www.typescriptlang.org/play/?isolatedDeclarations=true#code/C4TwDgpgBAKlC8UDeUwCcD2YBcUDOwaAlgHYDmUAvgNwBQtEAHmBmsFAMYYkFTfSIktKKkw4oAcgkAaWjXpMWbTt17AA7hgTJhorLimzKUAIZ4VPYHVoB6G1AhpMac9gAUDZq3ZdLUYAAWaBACOiLo+pIycvgmwER4AGZEEOYw1nYOTqyuHoreFryJGACuaNpC4WIG0cZmhex4cQnJqbB0QA

💻 Code

type T = { prop: string };

export const one = {
  prop: '',
};

export const two = {
  prop: '',
} as const;

// errors :(
export const three = {
  prop: '',
} satisfies T;

// errors :(
export const four = {
  prop: '',
} as const satisfies T;

🙁 Actual behavior

three and four both have errors, even though their satisfies-less counterparts do not have errors.

🙂 Expected behavior

all four variables should not error

Additional information about the issue

I guess that currently the presence of satisfies causes a different code path that ignores whether the underlying expression would be valid?
It would be good if TS was able to "look past" the satisfies so it can treat the code the same as if there was no satisfies.

This behaviour encourages you to do hacky things like this to "work around" the limitation.

export const three2 = {
  prop: '',
};
three2 satisfies T;

export const four2 = {
  prop: '',
} as const;
four2 satisfies T;

[uhyo]

In general, satisfies T affects type inference:

type T = { prop: "foo" | "bar" };

export const three1 = {
    //       ^?
    prop: "foo",
};

export const three2 = {
    //       ^?
    prop: "foo",
} satisfies T;

Playground

which is why (I guess) satisfies T is disallowed under isolatedDeclarations.

Not sure if the as const satisfies T case could be allowed though 🤔

[bradzacher]

I'd love to know if the "affects type inference" could be codified in a set of rules that would allow it to be used. For example if all it does is make TS treat literals as their literal type rather than their widened type - then you would easily be able to encode this into the ID rules.

But depends on all the things it does impact and change I guess.

[RyanCavanaugh]

e satisfies T puts a T contextual type on e, so if you have something like

type Bit = 0 | 1;
let n = { m: 0 } satisfies { m: Bit };

then you get n: { m: 0 } whereas without the satisfies you'd get n: { m: number }

There's not really a general way to detect ahead of time whether or not this would matter in the resulting type - you'd just have to run the inference one way, then the other. One of the design constraints we put on ID when accepting it as a feature was that we wouldn't be doing this sort of counterfactual analysis, since we don't really have architecture in place to do it.

[bradzacher]

What about as const satisfies T - wouldn't this NOT change the type and could thusly be ignored?

[typescript-bot]

This issue has been marked as "Question" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[bradzacher]

@RyanCavanaugh just so this doesn't get lost after getting auto closed - as per my previous comment, would it make sense for as const satisfies T to be allowed under the ID rules or would we rather not have it glance into the underlying expression for simplicity?

[RyanCavanaugh]

as const satisfies T has the same possibility. Consider this example:

type FuncObj = {
    func(n: number | string): number | string;
}

const m = { func: (n = 3) => n } as const satisfies FuncObj;
// Call is only OK because of the 'satisfies'
m.func("ok");

[bradzacher]

Thanks! I didn't realise satisfies could both narrow and widen the type -- so definitely this cannot be actioned then.