Repository navigation
Use unique symbol for well-known symbols #21603
Description
Activity
Ron Buckton (@rbuckton) thoughts?
If we do this update, we need a fix like #20018.
We can't fix this in the core library because of NodeJS, Core-JS, ES6-Shim, etc. also defining these as
symbol. I hope to get "lib" references in soon so that we can change NodeJS et. al. to reference the definitions inlib.es2016.symbol.wellknown.d.tsand then make this change.Reacted by Aluan HaddadRon Buckton (@rbuckton) lib references are in, what should we do here?
We unfortunately run into collisions in type definitions for packages like NodeJS that forward-declare some symbols. #26568 would help us to get to the point where the NodeJS type definitions could use
/// <reference lib="..." />without breaking in older versions of the compiler.#24738 fixes this gracefully with older versions of the node.d.ts by just assuming that if you wrote
symbolunder the globalSymbolConstructoryou meant to sayunique symbol.#24738 fixes this gracefully with older versions of the node.d.ts by just assuming that if you wrote symbol under the global SymbolConstructor you meant to say unique symbol.
I know we considered this, but it was more of a workaround. We need something like #26568 for other reasons and its more maintainable going forward.
That won't really help the community upgrade as much, though - they'll be forced to try and update their entire type heirarchy to depending on the latest version of all the declaration files. The workaround has the advantage that older declaration files continue to work (and continue to work with older versions of TS) and can be updated as needed.
they'll be forced to try and update their entire type heirarchy to depending on the latest version of all the declaration files.
This is usually the case when types are updated in a dependency. On definitely typed there are only a handful of packages that introduce this kind collision, which we can address easily enough once #26568 has landed in a development build. I'm not saying that the
symboltounique symbolworkaround might not still be needed, but its possible it won't be.Sorry for being a bother, but now that #26568 has been merged, is it possible to revisit this for TS 3.1?
#24738 would fix this in a manner that’s compatible with old
.d.tsfiles.Looks like this is a blocker to define correct
Array::concatsignature.The
Array::concatdecides whether they should spread the argument based onSymbol.isConcatSpreadableBut
Symbol.isConcatSpreadableis asymbolcurrently.Note:
The incorrect code below passed the type check.const a: number[][] = [[0]] const b: number[][] = a.concat([0])
Expected behavior:
Actual behavior: