Skip to content

Use unique symbol for well-known symbols #21603

Closed
@falsandtru

Description

@falsandtru

Expected behavior:

interface SymbolConstructor {
    readonly iterator: unique symbol;
}

Actual behavior:

interface SymbolConstructor {
    readonly iterator: symbol;
}

Activity

RyanCavanaugh

RyanCavanaugh commented on Feb 5, 2018

@RyanCavanaugh
Member

@rbuckton thoughts?

falsandtru

falsandtru commented on Feb 5, 2018

@falsandtru
ContributorAuthor

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

rbuckton

rbuckton commented on Feb 5, 2018

@rbuckton
Contributor

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

RyanCavanaugh commented on Aug 22, 2018

@RyanCavanaugh
Member

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

rbuckton

rbuckton commented on Aug 22, 2018

@rbuckton
Contributor

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

weswigham commented on Aug 23, 2018

@weswigham
Member

#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

rbuckton commented on Aug 23, 2018

@rbuckton
Contributor

#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

weswigham commented on Aug 23, 2018

@weswigham
Member

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

rbuckton commented on Aug 23, 2018

@rbuckton
Contributor

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

ntninja commented on Sep 13, 2018

@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

ExE-Boss commented on Jan 3, 2020

@ExE-Boss
Contributor

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

4 remaining items

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    RevisitAn issue worth coming back toSuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Participants

      @ntninja@weswigham@mmis1000@falsandtru@ExE-Boss

      Issue actions

        Use unique symbol for well-known symbols · Issue #21603 · microsoft/TypeScript