Incompatible TypedArrays are assignable to each other unless `lib.es2015.symbol.wellknown.d.ts` is used

[brad4d]

Bug Report

🔎 Search Terms

TypedArray, assignable, wellknown, Symbol

🕗 Version & Regression Information

AFAIK, this as been a problem ever since type .d.ts files were created for the TypedArray types.

The only way TS seems to distinguish between the various TypedArray types is by using the Symbol.toStringTag singleton string type defined in lib.es2015.symbol.wellknown.d.ts

When compiling for an ES5 environment, we would prefer not to include that .d.ts file.

Including it increases the risk that a developer will try to use some well-known Symbol value that cannot be polyfiled.
This could result in a runtime error later because the symbol doesn't exist.

Leaving it out makes TS think you can assign e.g. a UintArray to a Float32Array.

⏯ Playground Link

This example shows that it is possible to just assign a Uint8Array to a Float32Array when TS is configured for ES5.

https://www.typescriptlang.org/play?target=1&ts=3.3.3&ssl=1&ssc=1&pln=4&pc=1#code/GYVwdgxgLglg9mABAUwB4AdnQKozFADgEEAnEgQwE8AKEPQ0iygLkV32LKoEpWAxADZxyUAMwAmRlUQBvAFCJFiEsiggSSOhymUA3HIC+CxEA

💻 Code

function expectUint8Array(uint8Array: Uint8Array): Float32Array {
    return uint8Array; // no error here
}

🙁 Actual behavior

TS allowed assignment from Uint8Array to Float32Array with no error reported.

🙂 Expected behavior

TS should have reported an error.

[RyanCavanaugh]

This is the trade-off with structural typing -- types with different underlying semantics but identical public shapes are not differentiable. We fixed this with the symbol lib but don't have any way to fix this in older targets.

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.