Narrow String#toLowerCase/toUpperCase return types via Lowercase/Uppercase

[ljharb]

Make String.prototype.toLowerCase and toUpperCase preserve string-literal types in their return type, by typing them as
<T extends string>(this: T): Lowercase<T> and Uppercase<T> respectively.

For non-literal string receivers, Lowercase<string> resolves to string, preserving existing behavior. For literal receivers (e.g. "FOO".toLowerCase()), the result narrows to the corresponding literal ("foo").

Also filed as microsoft/typescript-go#3711

[typescript-bot]

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.

[typescript-bot]

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[RyanCavanaugh]

#44268 is not approved

[Renegade334]

For non-literal string receivers, Lowercase<string> resolves to string, preserving existing behavior. For literal receivers (e.g. "FOO".toLowerCase()), the result narrows to the corresponding literal ("foo").

That's not the case, Lowercase<string> isn't flattened to string.

interface String {
  foo<T extends string>(this: T): Lowercase<T>;
}

function returnFoo(s: string) {
  return s.foo();
}

let x = returnFoo("bar");
//  ^ Lowercase<string>

x = escape(x);
// TS2322: Type 'string' is not assignable to type 'Lowercase<string>'.

[ljharb]

whoops. i'll try to fix that.

[ljharb]

@RyanCavanaugh sorry, i didn't realize there was an issue already. is there any reason it can't be approved now?

[RyanCavanaugh]

Is there any reason it can't be approved now?

See discussion in the "Read More" valley starting at #44268 (comment)

[ljharb]

Thanks, and fair on the "default -100" - but i don't think it should matter if something breaks someone modifying globals or global types; that's the risk they're taking. i'm pretty sure it wouldn't break anyone who was already "polyfilling" this change (as i'm doing). As far as introducing a new type error, if they're using a literal type already, presumably they want it to stay as such, otherwise it'd already be typed as string, no?