[isolatedDeclarations] Add a syntactic form of computed property name which is always emitted as a computed property name about typescript

[weswigham]

I guess what I don’t understand is, if you’re already capable of doing this check for an arbitrary expression in the something position, what does the extra syntax buy you? It just feels like noise then.

Given

// @filename: node_modules/mod/index.ts
export const something = Math.random() ? 1 : 2;

then

import {something} from "mod";
export const a = {[something]: 1};

has no errors, while

import {something} from "mod";
export const a = {[something satisfies keyof]: 1};

issues an error on something: A satisfies keyof computed property name must be exactly a single string, number, or unique symbol literal type.

and

import {something} from "mod";
export const a = {[something]: 1};

emits

export const a: {[something: number]: number};

in accordance with the type of the resolved something, but

import {something} from "mod";
export const a = {[something satisfies keyof]: 1};

always emits, even if something cannot be resolved:

import {something} from "mod";
export const a: {[something]: number};

[weswigham]

It's basically a way to pull the error the declaration file would get from preserving the computed property name forward into the input file.

[fatcerberus]

… and issue an error on something satisfies keyof if something isn't exactly a single unique symbol, string literal, or number literal type (as is valid in the type position computed property name).

I guess what I don’t understand is, if you’re already capable of doing this check for an arbitrary expression in the something position, what does the extra syntax buy you? It just feels like noise then.

[fatcerberus]

Ah, so it's basically a syntactic hint not to widen it to an index signature, we always want it to show up as a computed property in types. satisfies keyof being that hint feels really awkward and non-intuitive, but that's strictly in 🚲 🏠 territory which it's probably too early for.

[AlCalzone]

Since Symbol.iterator is called out here, I just wanted to throw Symbol.asyncIterator into the ring because I didn't see it mentioned anywhere else and also produces an error currently.