[Experiment] feat(18497): New Feature Requesting for const Parameter

[a-tarasyuk]

Fixes #18497

The thing we've discussed (offline?) is just having a setting for "all parameters are always const", since in practice it isn't much of a burden to always write code that way. Introducing an actual inline const keyword is unlikely to happen due to this being an area clearly in TC39's domain. #18497 (comment)

[typescript-bot]

The TypeScript team hasn't accepted the linked issue #18497. If you can get it accepted, this PR will have a better chance of being reviewed.

[Andarist]

One concern related to the name of this setting - there are proposals for "const contexts" of parameters and this name can easily clash with those potential features.

A const context~ would allow literals to be inferred for schema-like arguments:

declare function constIdentity<const T>(a: T): T 

const result = constIdentity({ type: 'test' })
//    ^? const result: { type: 'test' }
// whereas without this feature this currently gets inferred to { type: string }

Note that I've obviously just invented some syntax and perhaps this feature would look completely differently (if it ever becomes a thing in the first place) but we can see how it's not that unlikely that const keyword could potentially be somehow involved in such a feature (as it would relate nicely to existing as const)

[fatcerberus]

True, but there’s also const foo = 42; which this is analogous to (prevents reassignment, vs. normal parameter semantics which act like let). So that potentially confusing overloading of the meaning of const already exists in TS.

[sandersn]

I like this idea, but it feels a bit like a lint rule in that I would want to disable it on purpose about 2% of the time. It's a lot like noUnusedParameters or noUnusedLocals, which I also wish were lint rules.

[a-tarasyuk]

It's a lot like noUnusedParameters or noUnusedLocals, which I also wish were lint rules.

@sandersn Do you think avoiding adding lint-like options would be better? It's just an experiment (from time to time I create experiments to get feedback from the TypeScript team or community), so I'm okay with closing it to reduce the number of PRs.

[sandersn]

I'd prefer to close the PR and keep the issue open until we decide on something final there. The semantics of a suggestion often change and the compiler code changes often, meaning that early work usually has to be redone.