Duplicate keys do not error

[crazyair]

🔎 Search Terms

🕗 Version & Regression Information

• This is a crash
• This changed between versions latest and latest_
• This changed in commit or PR _______
• This is the behavior in every version I tried, and I reviewed the FAQ for entries about _________
• I was unable to test this on prior versions because _______

⏯ Playground Link

No response

💻 Code

export const func = (demo: string) => {
    const obj = {
        [demo]: '1',
        [demo]: '1',
    };
    console.log(obj);
};

🙁 Actual behavior

no error

🙂 Expected behavior

error

Additional information about the issue

No response

[MartinJohns]

Related: #43186

[jcalz]

Presumably this isn't a bug but a limitation, since TS doesn't track identity of variables here. If the type of demo is string then the two utterances of demo are seen by TS as just two string-valued computed keys and therefore it won't complain (otherwise it would complain on {[demo1]: 0, [demo2]: 0} which we wouldn't want).

[crazyair]

Presumably this isn't a bug but a limitation, since TS doesn't track identity of variables here. If the type of demo is string then the two utterances of demo are seen by TS as just two string-valued computed keys and therefore it won't complain (otherwise it would complain on {[demo1]: 0, [demo2]: 0} which we wouldn't want).

ok，After mentioning it, I found that this is indeed the case, but there is no recommended writing that can avoid this problem. Because in this code, found a problem, only to find the key duplicate, was overwritten. It's hard.

[MartinJohns]

@jcalz Presumably it could check if the identifier is used twice in the object initialization. But I don't know how realistic this issue is and how expensive this check would be.

[RyanCavanaugh]

We could error on the same identifier; the odds a prior property initializer really mutate it seem low enough. But this also seems like a fairly rare mistake to make and would incur a relatively high cost to keep track of all the identifiers and check for uniqueness. We'd need to see more than a handful of instances of this particular problem happening and see the larger context of the code (maybe there's a better check, hard to say).

[crazyair]

We could error on the same identifier; the odds a prior property initializer really mutate it seem low enough. But this also seems like a fairly rare mistake to make and would incur a relatively high cost to keep track of all the identifiers and check for uniqueness. We'd need to see more than a handful of instances of this particular problem happening and see the larger context of the code (maybe there's a better check, hard to say).

eslint Performance will be better?

[crazyair]