Assertions involving values from dictionary literals aren't properly checked

[Rafer45]

Bug Report

🔎 Search Terms

type assertion keyof, "type string is not assignable",'string' as keyof

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about type casting

⏯ Playground Link

Playground link with relevant code

💻 Code

type Pirate = 'Luffy' | 'JackSparrow' | 'Blackbeard';
function logPirate(pirate: Pirate) { console.log(pirate); }

// Typechecks correctly
logPirate(({p: 'Luffy'} as {p: Pirate}).p);
logPirate(({p: 'not a pirate'} as {p: Pirate}).p);

// Doesn't complain, but doesn't actually check for the constraint
// Dangerous!
logPirate({p: 'Luffy' as Pirate}.p);
logPirate({p: 'not a pirate' as Pirate}.p);

🙁 Actual behavior

Casting a dictionary field that can’t be correct raises no compiler error nor warnings.

🙂 Expected behavior

Casting a dictionary field that can’t be correct raises a compiler error OR needlessly risky casts raise warnings.

[MartinJohns]

You're explicitly instructing the compiler to ignore the type issue.

[fatcerberus]

It seems like you either want satisfies or as const here. as type assertions are definitely the wrong tool in this situation.

[Rafer45]

You're explicitly instructing the compiler to ignore the type issue.

I understand -- my question isn't "how do I make this work and get it to typecheck?"; it's more like "is there a way to emit a warning for casting string literals into types they aren't?". It's a bit strange that logPirate(({p: 'Luffy'} as {p: Pirate}).p); is clever enough to typecheck, despite being a type assertion, while logPirate({p: 'Luffy' as Pirate}.p); isn't. The interaction with widening causes inconsistent typechecking behavior.

Put another way: as assertions don't seem to unconditionally instruct the compiler to ignore type issues, and this seems like an easy error, on the developer's end, for people to miss; I've seen many cases of {foo: 'bar' as keyof SomeDict} where {foo: 'bar' as const} would be a better choice -- is there a feasible warning that could be emitted, in the case of literals, for these bad casts?

[MartinJohns]

it's more like "is there a way to emit a warning for casting string literals into types they aren't?"

As fatcerberus mentioned, in TypeScript 4.9 you can use the satisfies operator.

as assertions don't seem to unconditionally instruct the compiler to ignore type issues, and this seems like an easy error, on the developer's end, for people to miss

Type assertions are a way to explicitly disable type checks. It's a way to instruct the compiler "my value is this type, even though you can't verify it, trust me on this". If you lie to the compiler, then it's not the compilers' fault things end up messy. There's only a rudimentary check if the two types overlap in some form, but this does not apply here.

The purpose of as is to disable type checks.

For any other suggestion I'd probably have to see a real use case, because in your example there's no need for any type assertion.

[Rafer45]

I understand that the problem with as abuse is that the developer is lying to the compiler; it just seems like there should be a warning when as is used for literals in this way, since it seems like a pretty common developer bug from what I've seen.

My specific context is here: https://github.com/Rafer45/experimental-extensions/blob/reao/storage-transcribe-audio/storage-transcribe-audio/functions/src/transcribe-audio.ts#L12

I've had some trouble replicating it in the typescript playground, but here, without the as const assertion, 'LINEAR16' was getting widened to the type string, requiring a cast (or, well, requiring as const, but I first did as keyof blahblah, which was a mistake I think other developers would make, and which I've seen elsewhere). I may be missing something obvious, though; thank you for your help so far.

[MartinJohns]

My specific context is here:

Simply typing the request variable would have prevented the issue.

[RyanCavanaugh]

as's intended behavior is to allow assertions that seem OK and disallow assertions that don't seem OK. There's no bright line here; in reality any assertion can be made OK by writing e as unknown as T so this is entirely a heuristical process designed to catch assertions that aren't plausibly correct.

In the case of literals from the same family, there's really no reason to ever write "foo" as "bar" -- you could always have written "foo" as const, or even usually just "foo" without loss of generality. There are some edge cases (usually around mutating side effects) where it's really useful to do this, and, as noted, any as really is as suspect as another. TS is just trying to hit the sweet spot in terms of only giving useful errors with this behavior.

[Rafer45]

Simply typing the request variable would have prevented the issue.

But it's more intuitive to type the 'LINEAR16' field, since the other fields weren't complaining, no? My claim is just that this is an easy enough mistake to make that it could merit a warning.

In the case of literals from the same family, there's really no reason to ever write "foo" as "bar" -- you could always have written "foo" as const, or even usually just "foo" without loss of generality.

Would it make sense to emit a warning when a literal is cast into its own family, then? Or to at least have a flag one could enable for that kind of warning? Since the cases where it's useful are edge cases?

[RyanCavanaugh]

You could write a lint rule to flag those cases if you find them objectionable in your own codebase.

[Rafer45]

Understood, thanks all for the discussion.

[MartinJohns]

But it's more intuitive to type the 'LINEAR16' field, since the other fields weren't complaining, no? My claim is just that this is an easy enough mistake to make that it could merit a warning.

Typing your variable will also cause excess property checks to work, informing you about unnecessary properties. Helpful when you accidentally misspelled an optional property.

Being explicit in the type you expect is intuitive to me.

[fatcerberus]

Just as a final note for the record: there’s no fundamental difference to the type system between randoString as "foo" vs. randoAnimal as Dog. In both cases you have a potentially unsafe downcast from a supertype to a subtype, and rejecting one in principle means rejecting the other, even if one might seem inherently more suspect.

That being said, the fact that "foo" as "bar" is directly allowed does surprise me, as it is very clearly a sidecast with no direct overlap between the types (they have a common supertype, but factorizing types isn’t generally something TS does).

[Rafer45]

Yeah, I understand why we would want to allow <nonLiteralExp> as "foo", just not why we would allow "non foo literal" as "foo", since there's no overlap.

But it's a developer error with as, not a compiler error -- I'll see what I can do to discourage it in my codebase.