Satisfies does not work with const assertion

[steverep]

Bug Report

🔎 Search Terms

satisfies, as const, literal

🕗 Version & Regression Information

• This is a crash
• I was unable to test this on prior versions because satisfies is new in 4.9.0 beta

⏯ Playground Link

Playground Link

💻 Code

type Colors = "red" | "green" | "blue";
type RGB = readonly [red: number, green: number, blue: number];
type Palette = Readonly<Record<Colors, string| RGB>>;

const palette1 = {
    red: [255, 0, 0],
    green: "#00ff00",
blue: [0, 0, 255]   
    // Expect to pass but throws error
} satisfies Palette as const;

🙁 Actual behavior

Fails with error:

'const' assertions can only be applied to references to enum members, or string, number, boolean, array, or object literals.

🙂 Expected behavior

No error because it is a literal and satisfies should not change the type. Also, other type assertions work fine, so const should as well.

[fatcerberus]

Try reversing the order of satisfies and as const. Having the satisfies clause first makes the compiler think you’re trying to apply as const to an expression instead of a bare literal, so it’s rejected for the same reason as (1 + 1) as const would be.

Also, other type assertions work fine, so const should as well.

This is immaterial as as const can’t be applied to arbitrary expressions like other type assertions can.

[steverep]

Try reversing the order of satisfies and as const. Having the satisfies clause first makes the compiler think you’re trying to apply as const to an expression instead of a bare literal, so it’s rejected for the same reason as (1 + 1) as const would be.

Yes, it works when reversed as I show in the playground link, but that just creates an unnecessary restriction to make sure everything in the satisfies type is readonly because the check will fail otherwise.

The compiler may be treating it as an expression, but it's not, and therein lies the bug.

[RyanCavanaugh]

The compiler may be treating it as an expression, but it's not, and therein lies the bug.

It absolutely is an expression, though.

Regardless, f(g(x)) === g(f(x)) isn't an identity. It's completely correct to say that you must write as const satisfies T, since that's the only order of applying those operations that works.

[fatcerberus]

Regardless, f(g(x)) === g(f(x)) isn't an identity.

I don’t think that’s the ask here, to be fair. It seems like the intent is to do the satisfies check first, and only then apply the transformations inherent to as const. Which is not currently possible.

[RyanCavanaugh]

Giving it some more thought, in the OP we can just reverse the order of operations, and it works, but arguably that actually doesn't generalize:

const j: { m: readonly [1, 2] } = { m: [1, 2] } satisfies { m: number[] } as const;

I'm not sure how to resolve this situation coherently. The implied algorithm seems to be:

• Check the expression { m: [1, 2] } and see if it's assignable to of { m: number[] }
• It is, because it has the type { m: number[] }
• Now check the expression { m: [1, 2] } as const and see if it's assignable to { m: readonly [1, 2] }
• It is

But in TypeScript, expressions only have one type. If we just "threaded through" the const context into the expression, this would happen:

• Check the expression { m: [1, 2] } in a const context and see if it's assignable to of { m: number[] }
• It's not, because an array literal in a const context acquires a readonly tuple type, and a readonly array isn't assignable to a mutable array

Another way to put it is that as const isn't a type-to-type transform, but rather it's a modifier that contextually changes the interpretation of literals, which is why it only makes sense to apply directly to expressions of a literal form.

The same thing is broadly true of contextual types in general, which again aren't a type-to-type transform, but rather have effects on the interpretation of literals and other expressions. In the original satisfies discussion we talked about whether the outer contextual type should matter -- I initially argued in favor of this because usually more contextual typing just only accepts more correct programs, but there were circularities and other problems introduced by this that ultimately made us decide against doing so. And already I've found some interesting cases where an unexpected benefit of satisfies is that you can use satisfies unknown to remove any outer contextual type in the rare cases where it's negatively affecting something. as const seems similar in spirit here and it'd be weird to thread-in the constness while not also threading-in the contextual type from an as T.

[fatcerberus]

Giving it some more thought, in the OP we can just reverse the order of operations, and it works, but arguably that actually doesn't generalize

Yep, hence this issue 😃

The implied algorithm seems to be … [snip]

Indeed this seems to be what OP wants to do.

[steverep]

It absolutely is an expression, though.

As I understood from your writing in #47920, e satisfies T should return typeof e, which implies to me (and probably most users?) that the satisfies operator should not affect any further operations on e. So at the very least the error returned seems incorrect and confusing.

Regardless, f(g(x)) === g(f(x)) isn't an identity. It's completely correct to say that you must write as const satisfies T, since that's the only order of applying those operations that works.

Well, that depends on f and g, but if I go ahead and follow that through:

f(x) = typeof(x as const)
g(x) = typeof(x satisfies T) = typeof x

f(g(x)) = typeof((typeof x) as const) = f(typeof x)
g(f(x)) = typeof(typeof(x as const)) = f(x)

In other words, if the satisfies operator is widening the literals to their primitive types, then sure they are not equivalent. But if the satisfies operator is doing nothing more than a check on x, then we should view g(x) = x, and they are absolutely equivalent so long as T is adjusted accordingly.

And stating that there's only one order that works is not correct either. The following works just fine:

const a = [x satisfies T1, y satisfies T2] as const;

I need much more time to digest your latter comments as I am not an expert on the compiler code, but thanks for starting to pull a 180. 👍

[fatcerberus]

That works because the const assertion applies to the array literal [ ... ], not the satisfies expressions directly.

What Ryan is saying is that the behavior you want isn't possible with the current way const assertions work because as const isn't a type transformation the way other type assertions are, i.e. it doesn't take something typed as number[] and give back a readonly [ 1, 2 ], it directly affects type inference of the literal it's applied to, namely by inferring narrower types to start with. So a naive implementation of this would still have the same problem as as const satisfies T does because it would be impossible to do the type check "before" the const assertion is applied (there's no "before").

[steverep]

That works because the const assertion applies to the array literal [ ... ], not the satisfies expressions directly.

That's the part I'm stuck on. Why would it ever apply to the satisfies expressions if they are purely checks?

... because it would be impossible to do the type check "before" the const assertion is applied (there's no "before").

Isn't that exactly what it does in the case of [x satisfies T] as const? I view that as check x then apply as const to the type. And I view x satisfies T as const the same way.

In any case, you guys clearly know the compiler way better than me, but I think my expectations of what it "should" do are fairly logical. Thanks for taking the time to explain.

[fatcerberus]

That's the part I'm stuck on. Why would it ever apply to the satisfies expressions if they are purely checks?

It wouldn’t—which is the problem here. as const applies to object/array literals, so even if satisfies T as const worked now, it wouldn’t do what you want—it would just infer the readonly types to begin with and subsequently fail the check. In order to do what you want the narrowing implied by a const assertion would need to be done as a separate step, which requires an architectural change to the compiler.

(in simpler terms { … } as const is one atomic expression potentially with a different type from { … } and breaking it apart, e.g. by putting a satisfies clause in the middle, makes no sense with the current architecture)