just because it handles the numbers as strings, is that really a concern though?
On the surface no, because TypeScript tries to enforce consistent access with the declared type.
But it still leaves a JavaScript type coercion footgun in place:
constrecord:Record<string|number,string>={0:'zero',1:'one',2:'two',};constoldOne=1;constnewOne='1';console.assert(record[oldOne]==='one');record[newOne]='newOne';// Oopsconsole.assert(record[oldOne]==='newOne');// Meanwhile TS flags this as an error// "This condition will always return 'false' since the types 'number' and 'string' have no overlap"// Actually it returns `true` due to type coercion; TS just doesn't like it...// console.assert(oldOne == newOne);// ...becauseconsole.assert(typeofoldOne!==typeofnewOne);// At least this works (ES2022)console.assert(Object.hasOwn(record,2));console.assert(Object.hasOwn(record,(2).toString()));
So TypeScript being typed had an opportunity to clean things up at least for objects to restrict property keys to strings and symbols but existing JavaScript code bases sometimes use numbers as property keys (for convenience) and not supporting that could have hurt adoption.
100% agree with you, just because we are Typescript we can't just leave things to it.
We should still validate everything.
Just one small question about your initial comment,
just because it handles the numbers as strings, is that really a concern though?
In most cases it's not really used anyway (just wondering why we should even care about that)
On the surface no, because TypeScript tries to enforce consistent access with the declared type.
But it still leaves a JavaScript type coercion footgun in place:
Similarly
So TypeScript being typed had an opportunity to clean things up at least for objects to restrict property keys to strings and symbols but existing JavaScript code bases sometimes use
number
s as property keys (for convenience) and not supporting that could have hurt adoption.