Storing a keyof to a string quoted number key produces TS2344: invalid constraint in declaration file

[rsesek]

TypeScript Version: 3.8.3 and 3.9.0-dev.20200309

Search Terms: [keyof quote], [keyof number declaration], [key number], [key quote], [object key number declaration]

Code

// test.ts
class C {
    readonly lines = {
        '1': 'abc',
        '2a': 'def'
    }
}

class Ref<T extends keyof C['lines']> {
    private _key: T;
    private _c = new C();

    constructor(key: T) {
        this._key = key;
    }

    value(): C['lines'][T] {
        return this._c.lines[this._key];
    }
}

const r1 = new Ref('1');
const r2 = new Ref('2a');

Expected behavior:

1. Run tsc --declaration test.ts
2. Run npx tsc --noEmit test.d.ts
3. No error is emitted

Actual behavior:
Step (2) actually produces an error:

2. Run npx tsc --noEmit test.d.ts

test.d.ts:13:23 - error TS2344: Type '"1"' does not satisfy the constraint '1 | "2a"'.

13 declare const r1: Ref<"1">;

When examining the output, note the two lines marked "BUG": the key in the lines object for 1 has been converted to number, but the Ref<"1"> is trying to access the key as a string.

// test.d.ts
declare class C {
    readonly lines: {
        1: string;     // BUG
        '2a': string;
    };
}
declare class Ref<T extends keyof C['lines']> {
    private _key;
    private _c;
    constructor(key: T);
    value(): C['lines'][T];
}
declare const r1: Ref<"1">;   // BUG
declare const r2: Ref<"2a">;

When tsc un-quotes the numeric key in C's definition, the Ref<"1"> produces a type mismatch.

Playground Link: Playground Link

Related Issues:

• Generic constraint generates a TS2344  #36852
• keyof has different literal type behavior when used in function signature #20602

[a-tarasyuk]

// test.ts
const x = {
    '1': 1,
    '2a': 1,
};

// test.d.ts
declare const x: {
    1: number;
    '2a': number;
};

// test.js
const x = {
    '1': 1,
    '2a': 1,
};

Which the right property name should be in the test.d.ts? 1 or '1'?

I noticed that TS converts property name from string to number explicitly

function createPropertyNameNodeForIdentifierOrLiteral(name: string, singleQuote?: boolean) {
  return isIdentifierText(name, compilerOptions.target) ? createIdentifier(name) : 
    createLiteral(isNumericLiteralName(name) ? +name : name, !!singleQuote);
}

function isNumericLiteralName(name: string | __String) {
  return (+name).toString() === name;
}

cc @RyanCavanaugh @weswigham

[RyanCavanaugh]

@ahejlsberg we could use some feedback here. This is pretty messy.

Our type system sort of traffics around whether property keys were quoted or not, and this observable effects in .d.ts emit and assignability when keyof is involved.

declare function getKeys<T>(x: T): keyof T;

// Both .d.ts emit as { 1: string }
const unquo = { 1: 'a' };
const quotd = { '1': 'a' };

// They are cross-assignable
let q1: typeof unquo = quotd;
let q2: typeof quotd = unquo;
// Error
let e1: keyof typeof unquo = null as any as keyof typeof quotd;
// Error
let e2: keyof typeof quotd = null as any as keyof typeof unquo;

// .d.ts emit here differs:
// 1
const unquoKey = getKeys(unquo);
// "1"
const quotdKey = getKeys(quotd);

Basically, the object type printback for an object will always "normalize" numeric-like property keys to their unquoted form, but keyof will retain the quotedness. This can induce the error shown in the OP:

// .d.ts emit is { 1: string, 2: string }
const mixer = { 1: 'a', "2": 'a' };

class X<K extends keyof typeof mixer> {
  constructor(obj: K) { }
}
// OK in original, OK in .d.ts
const unquoInst = new X(1);
// OK in original, error in .d.ts because "2" is not 2
const quotdInst = new X("2");

I don't know how we touch this without badly breaking "manual tuple" scenarios like { length: 1, 0: n }. Any thoughts?

[ahejlsberg]

I'm thinking that object types with numerically named properties (whether declared with quotes or without quotes) should have their keyof type include both representations (because you're permitted to index with either representation). So, keyof { 1: string } and keyof { '1': string } would both yield 1 | "1". Not sure how breaky that would be, but might be worth a try.