String case change methods should return intrinsic string manipulation types

[thw0rted]

lib Update Request

Configuration Check

My compilation target is ES2018 and my lib is ["ES2016", "dom"].

Missing / Incorrect Imprecise Definitions

At least toUpperCase and toLowerCase methods on String, maybe/probably also the Locale versions?

Sample Code

type LittleT = "t" | "tt";
type BigT = Uppercase<LittleT>;
declare const smol: LittleT;
const big: BigT = smol.toUpperCase(); // err, string is not assignable to "T" | "TT

Documentation Link

https://tc39.es/ecma262/#sec-string.prototype.tolowercase

Note

I'm not sure about the Locale versions of these methods because I don't know what algorithm the "intrinsic" Uppercase<T> / Lowercase<T> helper types are required to follow. (Do we need separate LocaleUppercase / LocaleLowercase helpers?)

Also worth mentioning: I think what I'm looking for is a return type of e.g. Uppercase<this>, which shouldn't have an impact on non-literal string types because Uppercase<string> is just string.

[Nixinova]

Related:

type Char = 'a' | 'A';

let char: Char = 'a';
char = char.toUpperCase();
//^ Error: Type 'string' is not assignable to type 'Char'.

String methods should be type <X extends string>(str: X): X not (str: string): string.

[kohlmannj]

I have a generated string union type definition like this:

export type Align =
  | 'LEFT'
  | 'CENTER'
  | 'RIGHT'
  | 'DEFAULT';

I also have an existing object literal export containing CSS-in-JS classNames that correspond to Lowercase<Align>:

export const textAlignClasses = {
  left: css``,
  center: css``,
  right: css``,
  /** Avoids TS7053 when using array notation */
  default: undefined,
};

Unfortunately, I cannot currently use .toLowerCase() on a string of type Align to safely key into textAlignClasses:

const textAlign: Align = 'DEFAULT';
const textAlignClass = textAlignClasses[textAlign.toLowerCase()];
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                       TS7053: Element implicitly has an 'any' type because expression of type 'string'
                       can't be used to index type '{ left: string; center: string; right: string; default: undefined; }'.
                       No index signature with a parameter of type 'string' was found on
                       type '{ left: string; center: string; right: string; default: undefined; }'.

I am current working around this limitation with a type assertion:

const textAlign: Align = 'DEFAULT';
const textAlignClass = textAlignClasses[textAlign.toLowerCase() as Lowercase<Align>];

[Nixinova]

String methods should be type <X extends string>(str: X): X not (str: string): string.

Hm, this doesn't seem possible without making the entire String interface generic...

[thw0rted]

@Nixinova it's only those 4 methods (upper/lower plus "locale" versions of same) that would need to change. None of them take a function argument, so the function can't (usefully) be generic.

My initial thought was, for non-primitive types, you can use this in a return value, but I'm actually not sure it's possible with a boxed type. In Playground, I tried interface String { toUpperCase(): Uppercase<this>; }, but this is not assignable to primitive, little-s string, which is the generic constraint of the Uppercase helper type.

I guess that means, the change I'm asking about might have to happen in the compiler rather than the type lib, which I recognize makes it less likely to happen.

[DetachHead]

i tried extending the String interface to add this but no luck since the base String interface doesn't use a generic

declare global {
    //TS2428: All declarations of 'String' must have identical type parameters.
    interface String<T extends string> {
        toLowerCase(): Lowercase<T>
        toUpperCase(): Uppercase<T>
    }
}

const foo = 'FOO'.toLowerCase() //TS2339: Property 'toLowerCase' does not exist on type '"FOO"'.

[ajafff]

Just use a generic this type on the method signatures:

interface String {
    toUpperCase<T extends string>(this: T): Uppercase<T>;
}

[thw0rted]

Thanks @ajafff , I thought I'd tried that earlier without success, but plugging my example into Playground works perfectly. Does this mean a PR would be as simple as changing the signature of those 4 methods?

[bfaulk96]

Any updates on this? looks like someone started implementing but then quit in December

[RyanCavanaugh]

This issue is "awaiting more feedback". This means we'd like to hear from more people who would be helped by this feature, understand their use cases, and possibly contrast with other proposals that might solve the problem in a simpler way (or solve many other problems at once).

If this feature looks like a good fit for you, please use the 👍 reaction on the original post. Comments outlining different scenarios that would be benefited from the feature are also welcomed.

[thw0rted]

If it helps to have a more detailed use case, I'm trying to exchange data between two systems, and I have an interface that describes the shape of the JSON returned / expected by their REST APIs. One uses lowercase keys, the other uses UPPERCASE, and I want the type checker to be happy with a case-change method, without having to add type assertions. If I do barKey = fooKey.toUppercase() as keyof BarData, I run the risk of missing the error when the structure of one or the other changes in an incompatible way.

[bfaulk96]

Thanks for the information, Ryan! My use case is very similar to the one provided by thw0rted