You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
typeT={[key: `prefix_${string}`]: number}consta: T={x: null}// Results in expected errorconstb={x: null}constc: T=b// Expected an error, but gives noneconstd: T={x: null}as{x: null}// Casting it to the same type when declaring it directly also results in no error
π Actual behavior
Error declaring a, and no error when declaring c or d.
π Expected behavior
Declaration of c and d to give the same error as when declaring a.
Additional information about the issue
If this is another case of #13948, the lack of errors on property keys makes sense to me. Although I am unsure if #27144 is responsible for the lack of errors on value type or not.
Regardless of whether to expect an error or not, I would assume the declaration of a and c to produce the same result.
The text was updated successfully, but these errors were encountered:
{ x: null } is a valid subtype of { [key: `prefix_${string}`]: number }, so it is expected to get no error when declaring c or d. The error you got when declaring a is caused by Excess Property Checks.
{ x: null } is a valid subtype of { [key: `prefix_${string}`]: number }, so it is expected to get no error when declaring c or d. The error you got when declaring a is caused by Excess Property Checks.
Why is { x: null } is a valid subtype of { [key: prefix_${string}]: number } ?
{ x: null } is a valid subtype of { [key: `prefix_${string}`]: number }, so it is expected to get no error when declaring c or d. The error you got when declaring a is caused by Excess Property Checks.
Why is { x: null } is a valid subtype of { [key: prefix_${string}]: number } ?
Because all keys in { x: null } which match prefix_${string} (0 keys) are of type number. x is an excess property which gets ignored because it isnt constrained by T.
The error with const a: T = { x: null } is Object literal may only specify known properties, and 'x' does not exist in type 'T'., but const c: T = b doesnt involve an object literal, so no error.
To clarify on the above point: The index signature doesnβt constrain the set of allowed keys, but only the types of the properties it matches. You may have intended that objects could only contain properties with names starting with prefix_, but thatβs not possible to enforce without #12936.
Note that this is much less misleading in TS 5.3 (currently in beta), where the βnot assignableβ wording is removed from the error message.
π Search Terms
"template literal" "computed property keys"
π Version & Regression Information
β― Playground Link
https://www.typescriptlang.org/play?declaration=false&ts=5.2.2#code/C4TwDgpgBAKlC8UDeUDaBrCIBcUAGYAThAGYCWAHgPoAkSAzsIWQHYDmAvngLq4sCuAWwBGEQlA4AoAMYB7FoygBDXHEQoKffgBttEqAHoDUAEoR6O4PSisoECpGnAIAEzuFCswpJnzFwhGQoTSgBXQlfBWAoaVVAgKMoAFEHCCdXZRZ3T0IAGihhfmi2MgA3c1D5CB85KKgXOPVgrXCOZWsNFr02xIBhJUZWNhto4FkoYAALaHolQWhQSCgAd2mslzTtJWZ2EfqyYidtEGVtenHiC20rGyyWcbEcoA
π» Code
π Actual behavior
Error declaring
a
, and no error when declaringc
ord
.π Expected behavior
Declaration of
c
andd
to give the same error as when declaringa
.Additional information about the issue
If this is another case of #13948, the lack of errors on property keys makes sense to me. Although I am unsure if #27144 is responsible for the lack of errors on value type or not.
Regardless of whether to expect an error or not, I would assume the declaration of
a
andc
to produce the same result.The text was updated successfully, but these errors were encountered: