Prevent readonly symbols widening

[Andarist]

closes #53276 , cc @weswigham

[Andarist]

I think that perhaps as const should preserve the uniqueness of symbols created in object literals but that's not strictly related to this issue so I think it should be fine to tackle this separately if that's something that you think should be done.

[Andarist]

I have a feeling that passing type.symbol.valueDeclaration to isValueSymbolAccessible here might not be 100% correct but so far I wasn't able to write a test that would fail with this

[Andarist]

@jakebailey would u mind creating a playground for this one? :)

[jakebailey]

@typescript-bot pack this

[typescript-bot]

Heya @jakebailey, I've started to run the tarball bundle task on this PR at d7dc3f9. You can monitor the build here.

[typescript-bot]

Hey @jakebailey, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/156395/artifacts?artifactName=tgz&fileId=1A95C96C6617FFB7587CCF405EF9CDDDD6B202F8CA34673E41874DDECD34143302&fileName=/typescript-5.3.0-insiders.20230809.tgz"
    }
}

and then running npm install.

---

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/[email protected]".;

[weswigham]

Hrm, when I opened the original issue I had a specific kind of fix in mind - right now all literal types have "freshness" that determines if we widen them or not at specific locations. unique symbols are literal types which currently lack fresh and un-fresh variants, and instead just always widen (and always widen in more places than most other literal types do). Freshness for unique symbols is a bit more complicated though - they don't come from a literal, per sey, so it's not that expression literals produce fresh types, but rather that the Symbol() call and... const assignments of unique symbols (? or at least references to members of the global Symbol constructor?) produce "fresh" (widening) variants of the types.

In any case, I don't feel great about widening being controlled by an accessibility check - that's probably not good for perf, and doesn't actually check completely what you'd hope it does - it checks if the symbol is accessible via simple dotted accesses from a name at the given location, but the symbol may, for example, be a member of a type and is thus still "accessible" but via an indexed access on a type symbol... or something more convoluted. I just don't feel like accessibility determining widening behavior has great rules or a great feel, and doesn't feel like it can be reliably replicated into a declaration file to preserve the widening behavior.

I dunno, I've talked about it before among the team and maybe @rbuckton has more thoughts on why unique symbols so aggressively widen today.

[Andarist]

How would the narrowed-down fix for your issue look like? Checking if it comes from the global Symbol would suffer from some of the problems you just mentioned - unless I'd build a reverse lookup of what symbols are available on the global Symbol.

[sandersn]

Note: this PR blocks #42104.

@weswigham would you be able to look at this again? It sounds like you wanted quite a different approach from what's currently here.

[jakebailey]

I think this predated our design meeting in which we basically said "symbol should do widening just like literals but doesn't" such that a final fix will probably be to rework symbols to have some sort of freshness. I just haven't had time to do so.

That or I've misunderstood the situation.

[Andarist]

I think this predated our design meeting in which we basically said "symbol should do widening just like literals but doesn't" such that a final fix will probably be to rework symbols to have some sort of freshness. I just haven't had time to do so.

If you are already committed to this kind of change then it's probably best to close this PR.