Intrinsic types remove widening on literal types

Bug Report

🔎 Search Terms

intrinsic, uppercase, lowercase, widening

🕗 Version & Regression Information

Occurs in Nightly (5.0.0-dev.20221118) and every version I tried going back to 4.1.5

⏯ Playground Link

Playground link with relevant code

💻 Code

declare const x: boolean;
declare function capitalize<T extends string>(it: T): Capitalize<T>;

// example 1
let greeting1 = "hello";
if(x) {
  greeting1 = "goodbye"; // allowed
}

// example 2
let greeting2 = capitalize("hello");
if(x) {
  greeting2 = capitalize("goodbye"); // type error
}

This example is adapted from @RyanCavanaugh’s example here.

🙁 Actual behavior

Reassigning a new string to greeting1 succeeds, but reassigning one to greeting2 fails.

🙂 Expected behavior

The widening behavior for standard literal types (like "hello") should not be different from the behavior of the type produced by Capitalize<"hello">; if the widening behavior were the same, greeting2 would also have its type inferred as string, and would accept a new string being assigned to it.

Having inconsistent widening like this seems unintuitive and possibly unintentional. Concretely, it also makes it impossible to use an intrinsically-typed value in a let statement (as shown), which creates a similar problem in @RyanCavanaugh’s original example in #44268.

[Andarist]

The widening that happens here is completely different though. The wrapping capitalize call changes everything here. You always~ get an inferred type from the given expression based on the surrounding context.

When assigning a string to a let variable the type of this variable becomes string when you pass it through a function that can infer a different type based on its arguments then u will get the type returned by that function. It matches your expectations here - otherwise, you wouldn’t use a Capitalize<T> there as Capitalize<string> is roughly equivalent to just string. So clearly you have wanted to get a literal type there.

From that moment the type of that variable is fixed - it won’t widen on the following assignments. It’s basically the same case as this one:

declare const x: boolean;

let greeting1 = "hello";

if (x) {
  greeting1 = 42; // Type 'number' is not assignable to type 'string'.(2322)
}

This one is actually “fixable” by using “auto” types like here (by not annotating the greeting1’s type):

declare const x: boolean;

let greeting1
greeting1 = "hello";

if (x) {
  greeting1 = 42; 
}

declare function acceptStr(a: string): void
declare const x: boolean;

let greeting1
greeting1 = "hello";

if (x) {
  acceptStr(greeting1) // ok, the auto type is `string`
  greeting1 = 42; // ok, `number` gets pushed locally to the automatically created union~
  acceptStr(greeting1) // not ok, the auto type is `string | number`: Argument of type 'number' is not assignable to parameter of type 'string'.(2345)
}

So, in a way, you could leverage the auto types in your example: TS playground. This would look quite weird though, so I would advise you to just provide an explicit generic argument like here.

Perhaps what you’d like to request here is to annotate a variable as “auto” - so you wouldn’t have to add a generic type param and you wouldn’t have to split the initial variable declaration and the initial value assignment

[ethanresnick]

Hey @RyanCavanaugh, sorry to hear you were sick. Welcome back, and I hope you were able to have a nice thanksgiving.

There aren’t long-standing years-missed bugs around widening/nonwidening literal types – edge cases, yes? But it’s not fundamentally broken in some obviously-fixable way; the behavior in https://github.com/microsoft/TypeScript/pull/24310 has been present for four years now, without substantial complaint as far as I’m aware.

I agree: there’s clearly not a huge amount of pain caused by the current system. My hope would still be that at least some of these edge cases are avoidable, without complicating the underlying rules, but I confess that I can’t think of concrete proposal right now that would definitely improve things enough to justify the breakage.

I think @fatcerberus is right that undoing #24310 would address the OP and wouldn’t produce problems on your “Gordian Knot” example — but it would reintroduce the issue that #24310 was used to solve, and that’s where I’m stumped.

In the example from #23649:

export function keys<K extends string, V>(obj: Record<K, V>): K[] {
  return Object.keys(obj) as K[]
}

declare const langCodeSet: Record<"fr" | "en" | "es" | "it" | "nl", true | undefined>;
const langCodes = keys(langCodeSet);

langCodes is supposed to be an array of string literals, rather than string[].

Had #24310 never been introduced, I think I would’ve tried to accomplish that in some other way, rather than cueing off of the extends string on the generic. E.g., maybe #23649 could’ve been solved with a rule saying that the literal type inferred for K shouldn’t be widening because K is used in an object key position (in the Record mapped type). I’m not saying that would’ve been an ideal (or even workable) rule, but just that maybe there were potential alternatives before #24310 was added.

However, given that #24310 has been introduced, I bet a bunch of people now are relying on getting literal types in all sorts of places where they were previously being widened, so rolling back #24310 now would probably be too disruptive.

I looked in my own code and found a function like this:

function gqlSuccessResult<T extends object, U extends string>(result: T, name: U) {
  return {  
    __typename: name, 
    ...result 
  };
}

In that example, I’m relying on #24310 to give me a literal type for the inferred type of the __typename key, and I can’t think of an alternate rule (that doesn’t require any code changes) that would do that.

Had #24310 not been introduced, I might’ve proposed addressing that use case like this:

function gqlSuccessResult<T extends object, U extends string>(result: T, name: U) {
  return {  __typename: name as const, ...result };
}

In the above snippet, I’m extending the set of places where as const can legally appear; instead of being allowed only on literals, I’m saying it’d be allowed on name because name’s type is constrained such that it might have a literal type, and the as const there would mean “don’t make the literal type widen”.

But, again, now that people are relying on #24310, I doubt the breakage would be justified.

So, idk, maybe I’ll keep noodling on this and, for now, I’ll just open a separate issue for the one concrete bug that I think this thread identified, which is that foo as typeof foo should always be a no-op (imo).