Use unique symbol for well-known symbols

[falsandtru]

Expected behavior:

interface SymbolConstructor {
    readonly iterator: unique symbol;
}

Actual behavior:

interface SymbolConstructor {
    readonly iterator: symbol;
}

[RyanCavanaugh]

@rbuckton thoughts?

[falsandtru]

If we do this update, we need a fix like #20018.

[rbuckton]

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 in lib.es2016.symbol.wellknown.d.ts and then make this change.

[RyanCavanaugh]

@rbuckton lib references are in, what should we do here?

[rbuckton]

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.

[weswigham]

#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.

[rbuckton]

#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.

[weswigham]

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.

[rbuckton]

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 symbol to unique symbol workaround might not still be needed, but its possible it won't be.

[ntninja]

Sorry for being a bother, but now that #26568 has been merged, is it possible to revisit this for TS 3.1?

[ExE-Boss]

#24738 would fix this in a manner that’s compatible with old .d.ts files.

[mmis1000]

Looks like this is a blocker to define correct Array::concat signature.

The Array::concat decides whether they should spread the argument based on Symbol.isConcatSpreadable

But Symbol.isConcatSpreadable is a symbol currently.

Note:
The incorrect code below passed the type check.

const a: number[][] = [[0]]
const b: number[][] = a.concat([0])