Typescript: 記号による索引付けを許可する

これは、 @ JsonFreemanが取り組んでいるES6シンボルサポートの一部です。 コードサンプルは、次のリリースでサポートされる予定です。

@wereHamster 、プルリクエスト＃1978を使用すると、これは合法になるはずであり、 obj[theAnswer]タイプはanyます。 あなたが探しているものにはそれで十分ですか、それともより強力なタイピングが必要ですか？

シンボルでインデックス付けされるプロパティのタイプを指定することは可能ですか？ 次のようなもの：

var theAnswer = Symbol('secret');
interface DeepThought {
   [theAnswer]: number;
}

そのPRのコメントに基づいて、いいえ：

_これは、オブジェクトが任意のシンボルキーを持つマップとして機能できるようにするシンボルインデクサーには適用されません。_

@wereHamsterは

var theAnswer = Symbol('secret');
interface DeepThought {
    [Symbol.toStringTag](): string; // Allowed
    [theAnswer]: number; // not allowed
}

次のレベルのサポートは、シンボルインデクサーを許可することです。

var theAnswer = Symbol('secret');
interface DeepThought {
   [s: symbol]: number;
}
var d: DeepThought;
d[theAnswer] = 42; // Typed as number

これは私たちのレーダーにあり、簡単に実装できます。

最強のレベルはあなたが求めているものであり、それは次のようなものです。

var theAnswer = Symbol('secret');
var theQuestion = Symbol('secret');
interface DeepThought {
   [theQuestion]: string;
   [theAnswer]: number;
}
var d: DeepThought;
d[theQuesiton] = "why";
d[theAnswer] = 42;

これは本当に素晴らしいことですが、これまでのところ、そのための賢明な設計は考えられていません。 最終的には、タイプをこれらのシンボルの実行時の値に依存させることにかかっているようです。 それは明らかに有用なことなので、私たちはそれについて考え続けます。

私のPRでは、少なくともシンボルを使用してオブジェクトの値をプルアウトできるはずです。 anyになりますが、エラーは発生しなくなります。

@wereHamster私はあなたが興味を持っているかもしれない小さな記事＃2012をしました。

リクエスト＃1978をマージしましたが、この変更で提供した以上のものを要求しているように見えるため、このバグは開いたままにしておきます。 ただし、私の変更により、元のエラーはなくなります。

@wereHamsterここでもっと何が起こってほしいかについての最新情報を投稿できますか？ 私たちが何を実装したのか、あなたが何を投稿したのか、すぐにはわかりませんでした

symbolがインデクサーとして有効なタイプになるときのアイデアはありますか？ これはコミュニティPRとしてできることですか？

これにはPRをします。 @JsonFreemanは、発生する可能性のあるいくつかの問題の詳細を提供できます。

実際、シンボルインデクサーを追加するのは非常に簡単だと思います。 割り当て可能性、型引数の推論などの点でどちらとも互換性がないことを除いて、数値や文字列と同じように機能します。主な課題は、適切な場所すべてにロジックを追加することを忘れないようにすることです。

@RyanCavanaugh 、最終的にhttps://github.com/Microsoft/TypeScript/issues/1863#issuecomment -73668456typecheckに最後の例があると便利です。 ただし、必要に応じて、この問題を複数の小さな問題に分割して、互いに積み重ねることができます。

この面で何か更新はありましたか？ AFAIUの最新バージョンのコンパイラは、 https： //github.com/Microsoft/TypeScript/issues/1863#issuecomment-73668456で説明されている最初のレベルのみをサポートし

この変更のPRを喜んで受け入れます。

2つの別々の問題として2つのレベルを追跡する価値があるかもしれません。 インデクサーはかなり単純に見えますが、ユーティリティは明確ではありません。 一定の追跡による完全なサポートは非​​常に難しいようですが、おそらくもっと便利です。

一定の追跡は、 https：//github.com/Microsoft/TypeScript/issues/5579ですでに追跡されてい

了解しました、理にかなっています。

@JsonFreeman @mhegazy問題は＃12932で入手できます

ユースケースをリングに投げ込むと思っただけです。 任意のオブジェクトプロパティと照合するためのプレーンテキストキーと、照合演算子を指定するための記号を指定することで、クエリを記述できるツールを作成しています。 よく知られている演算子に記号を使用することで、よく知られている演算子のキーと同じキーを持つフィールドと演算子を照合するというあいまいさを回避します。

JavaScriptで明示的に許可されているのとは対照的に、シンボルをインデックスキーとして指定できないため、多くの場所で<any>にキャストする必要があり、コードの品質が低下します。

interface Query {
  [key: string|symbol]: any;
}

const Q = {
  startsWith: Symbol('startsWith'),
  gte: Symbol('gte'),
  lte: Symbol('lte')
}

const sample: Query = {
  name: {
    [Q.startsWith]: 'M',
    length: {
      [Q.lte]: 25
    }
  },
  age: {
    [Q.gte]: 18
  }
};

クエリエンジンが検査する必要のあるデータの多様性を考えると、 $文字などの「ありそうもない」最初の文字の使用は適切な妥協案ではありません。

こんにちは、みんな。 これに動きはありますか？ 私はそれが必要なので、必要な変更を喜んで提供します。 ただし、これまでTSに貢献したことはありません。

@mhegazy @RyanCavanaugh皆さんが非常に忙しいことは知っていますが、機会があればぜひ参加してください。 シンボルは、ライブラリとフレームワークを設計するための非常に重要なツールであり、インターフェイスでシンボルを使用する機能の欠如は、明確な問題点です。

何か進行中はありますか？ この機能がサポートされることを心から願っています。

https://github.com/Microsoft/TypeScript/pull/15473は関連しているように見えます。

ええ、今日もこれを探しています、これは私がWebstormで見るものです：

それは実際に機能します

var test: symbol = Symbol();

const x = {
    [test]: 1
};

x[test];

console.log(x[test]);

console.log(x['test']);

しかし、 xのタイプは正しくなく、次のように推測されます。

{
  [key: string]: number
}

ええ、今日もこれを探しています、これは私がWebstormで見るものです：

WebStorm、intelliJIDEAなどでデフォルトで有効になっているJetBrains独自の言語サービスに注意してください。

これはTS2.7で機能します

const key = Symbol('key')
const a: { [key]?: number } = {}
a[key] = 5

これに関する更新はありますか？

私の問題：

export interface Dict<T> {
  [index: string]: T;

  [index: number]: T;
}

const keyMap: Dict<number> = {};

function set<T extends object>(index: keyof T) {
  keyMap[index] = 1; // Error Type 'keyof T' cannot be used to index type 'Dict<number>'
}

ただし、シンボルをインデックスタイプにすることはできないため、これも機能しません。

export interface Dict<T> {
  [index: string]: T;
  [index: symbol]: T; // Error: An index signature parameter type must be 'string' or 'number'
  [index: number]: T;
}

予想される行動：
symbolは有効なインデックスタイプである必要があります

実際の動作：
symbolは有効なインデックスタイプではありません

as string | numberをキャストして回避策を使用することは、私には非常に悪いようです。

util.promisify.customはTypeScriptでどのように使用されることになっていますか？ 定数シンボルの使用は現在サポートされているようですが、明示的に定義されている場合に限ります。 したがって、これは有効なTypeScriptです（ fが初期化されていないことを除いて）：
typescript const custom = Symbol() interface PromisifyCustom<T, TResult> extends Function { [custom](param: T): Promise<TResult> } const f: PromisifyCustom<string, void> f[custom] = str => Promise.resolve()
しかし、場合promisify.custom代わりに使用されるcustom 、参照しようとf[promisify.custom]エラーになりElement implicitly has an 'any' type because type 'PromisifyCustom<string, void>' has no index signature. ：
typescript import {promisify} from 'util' interface PromisifyCustom<T, TResult> extends Function { [promisify.custom](param: T): Promise<TResult> } const f: PromisifyCustom<string, void> f[promisify.custom] = str => Promise.resolve()
関数のpromisify.customフィールドに割り当てたいのですが、（上記の動作を考えると）これを行う唯一の方法は関数をany型にキャストすることであるようです。

シンボルがキーインデックスとして許可されていない理由がわかりません。以下のコードは機能し、Typescript 2.8で受け入れられますが、Typescript2.9では許可されていません。

/**
 * Key can only be number, string or symbol
 * */
export class SimpleMapMap<K extends PropertyKey, V> {
  private o: { [k: string ]: V } = {};

  public has (k: K): boolean {
    return k in this.o;
  }

  public get (k: K): V {
    return this.o[k as PropertyKey];
  }

  public set (k: K, v: V) {
    this.o[k as PropertyKey] = v;
  }

  public getMap (k: K): V {
    if (k in this.o) {
      return this.o[k as PropertyKey];
    }
    const res = new SimpleMapMap<K, V>();
    this.o[k as PropertyKey] = res as any as V;
    return res as any as V;
  }

  public clear () {
    this.o = {};
  }
}

私は以下を試しましたが、これは私にとってより「正しい」ですが、Typescriptコンパイラの両方のバージョンで受け入れられません

/**
 * Key can only be number, string or symbol
 * */
export class SimpleMapMap<K extends PropertyKey, V> {
  private o: { [k: K ]: V } = {};

  public has (k: K): boolean {
    return k in this.o;
  }

  public get (k: K): V {
    return this.o[k];
  }

  public set (k: K, v: V) {
    this.o[k] = v;
  }

  public getMap (k: K): V {
    if (k in this.o) {
      return this.o[k];
    }
    const res = new SimpleMapMap<K, V>();
    this.o[k as PropertyKey] = res as any as V;
    return res as any as V;
  }

  public clear () {
    this.o = {};
  }
}

このチケットのステータスは、提案しているのが望ましい動作であることを示していますが、コアチームは現時点では、この機能拡張を追加するためのリソースをコミットしておらず、コミュニティに公開して対処しています。

@beenotungこれは理想的な解決策ではありませんが、投稿したクラスがそのような動作を必要とする唯一の場所であると仮定すると、クラス内で安全でないキャストを行うことができますが、クラスとメソッドのシグネチャを同じに

/**
 * Key can only be number, string or symbol
 * */
export class SimpleMapMap<K extends PropertyKey, V> {
  private o: { [k: string]: V } = {};

  public has(k: K): boolean {
    return k in this.o;
  }

  public get(k: K): V {
    return this.o[k as any];
  }

  public set(k: K, v: V) {
    this.o[k as any] = v;
  }

  public getMap(k: K): V {
    if (k in this.o) {
    return this.o[k as any];
    }

    const res = new SimpleMapMap<K, V>();
    this.o[k as any] = res as any as V;
    return res as any as V;
  }

  public clear() {
    this.o = {};
  }
}

署名は同じであるため、このクラスを使用するたびに、型の検証が正しく適用され、この問題が解決されたら、このクラスを変更するだけで済みます（コンシューマーに対して透過的になります）。

コンシューマーの例は次のようなものです（この問題が修正された場合、コードを変更する必要はありません）。

const s1 = Symbol(1);
const s2 = Symbol(2);

let m = new SimpleMapMap<symbol, number>()
m.set(s1, 1);
m.set(s2, 2);
m.get(s1);
m.get(1); //error

Typescript 3.0.1、これに噛まれました。
symbolを受け入れるレコードが欲しいのですが、TSでは許可されません。

この号が発行されてから3。5年になりますが、今すぐシンボルをいただけますか🙏

皮肉なことに、TSはそれ自体と矛盾しています。
TSはkeyof any = number | string | symbolます。

しかし、あなたがrecord[symbol] TSは言うことを拒否します
_Type'symbol 'はインデクサーとして使用できません_。

ええ、私は悲しいことにしばらくこれに苦しんでいます、このトピックに関する私の最新の質問：

https://stackoverflow.com/questions/53404675/ts2538-type-unique-symbol-cannot-be-used-as-an-index-type

@RyanCavanaugh @DanielRosenwasser @mhegazy更新はありますか？ この号は4歳の誕生日が近づいています。

誰かが私を正しい方向に向けることができれば、私はそれをやってみることができます。 一致するテストがある場合は、さらに良いです。

@ jhpratt ＃26797にPRがあります（よく知られているシンボルに関する警告に注意してください）。 ＃28581にそれに関する最近の設計会議のメモがあります（ただし、そこには解決策は記録されていません）。 そのPRがここで保留されてます。 それはフリンジ/影響の少ない問題と見なされているようですので、PRへの賛成票を増やすことで問題の知名度を上げることができるかもしれません。

@yortusに感謝します。 私はライアンに、PRがまだ3.2で計画されているかどうか尋ねました。これは、マイルストーンによって示されています。 うまくいけば、それは事実であり、これは解決されるでしょう！

@yortusが指摘するPRは大きな変化のようですが、
このバグの修正は非常にマイナーなものではありませんか？ たとえば、条件チェックにorステートメントを追加します。
（変更する場所はまだ見つかりません。）

ここの一時的な解決策https://github.com/Microsoft/TypeScript/issues/24587#issuecomment-412287117 、ちょっと醜いですが、仕事を成し遂げ

const DEFAULT_LEVEL: string = Symbol("__default__") as any;

別のhttps://github.com/Microsoft/TypeScript/issues/24587#issuecomment-460650063 、リンターh8 any

const ItemId: string = Symbol('Item.Id') as unknown as string;
type Item = Record<string, string>;
const shoes: Item = {
  name: 'whatever',
}
shoes[ItemId] = 'randomlygeneratedstring'; // no error

{ name: 'whatever', [Symbol(Item.Id)]: 'randomlygeneratedstring' }

シンボルを使用する際に気付いた落とし穴の1つは、child_processモジュールを含むプロジェクトがある場合です。はい、2つのプロセス間でタイプ/列挙型/インターフェイスを共有できますが、シンボルは共有できません。

これを解決することは本当に素晴らしいことですが、シンボルはキーを汚染せずにオブジェクトを追跡し、マップ/セットを使用する必要がないという点で非常に優れています。さらに、近年のベンチマークでは、シンボルへのアクセスは文字列へのアクセスと同じくらい高速であることが示されています。 /数字キー

編集：このアプローチはRecord<X,Y>のみ機能し、 Interfaces 。 // @ts-ignoreはまだ構文的に正しく、JSに適切にコンパイルされるため、今のところ

ただし、シンボルを含む行で// @ts-ignoreを使用する場合、実際にはそのシンボルのタイプを手動で指定することが可能です（そして役立ちます）。 VSCodeはまだそれを拾っています。

const id = Symbol('ID');

interface User {
  name: string;
  age: number;
}

const alice: User = {
  name: 'alice',
  age: 25,
};

// @ts-ignore
alice[id] = 'maybeSomeUUIDv4String';

// ...

// then somewhere, when you need this User's id

// @ts-ignore
const id: string = alice[id];

console.log(id); // here you can hover on id and it will say it's a string

誰かがこれを修正するために何かを始めたかどうかはわかりませんが、そうでない場合は、私は今持っています。

しかし、私の時間は限られており、Typescriptのソースについての知識はありません。 フォーク（https://github.com/Neonit/TypeScript）を作成しましたが、プルリクエストはまだありません。これは、未完成の（？）変更で開発者を虐待したくないためです。 みんなに私のフォークにできることを寄付してもらいたいと思います。 その時は最終的にPRを出します。

これまでのところ、インターフェイスのインデックスタイプの制限を修正する方法を見つけました。 それ以上あるかどうかはわかりません。 TS 3.4では、修正なしでシンボルを使用してオブジェクトにインデックスを付けることができました。 （ https://www.typescriptlang.org/play/#src = const％20o％20％3D％20％7B％7D％3B％0D％0Aconst％20s％20％3D％20Symbol（ 's'）％3B ％0D％0A％0D％0Ao％5Bs％5D％20％3D％20123％3B）

私が見つけたものを確認するために私のコミットを見てください： https ：

行方不明：

• テスト：TSのテストがどのように編成および構造化されているかを調べる時間がありませんでした。
• ローカリゼーション：診断メッセージは、英語のバリアントに対してのみ更新されています。 たぶん、他の言語はまだ古いメッセージを受け取ります。 知りません。 とにかく私はドイツ語の翻訳しか提供できませんでした。

これが何年も待った後、ようやく物事が始まることを願っています。

修正は良さそうです。 TypeScript開発者はそれを見ることができますか？

こんにちは、これについて何か進展はありますか？

これについてSOスレッドを開いたところです： https ：

なぜそれが不可能なのですか？ symbol numberような別のプリミティブ型ではありません-では、なぜ違いがあるのでしょうか？

こんにちは、これについて何か進展はありますか？

5年が経ちました！

C ++がクロージャを取得するのにどれくらいの時間がかかったかを信じるつもりはありません😲

笑フェアですが、C ++はクロージャを持つ言語のスーパーセットとしてそれ自体をマーケティングしていません:-p

@ljharbはその馬を殴り続けます、それはまだけいれんしています😛

新しいランタイムをターゲットにしている人は、 Map使用してみませんか？ 多くの開発者がMapが存在することを知らないことが逸話的にわかったので、私が見逃している別のシナリオがあるかどうか知りたいです。

let m = new Map<symbol, number>();
let s = Symbol("arbitrary symbol!");

m.set(s, 1000);
let a = m.get(s);

マップとオブジェクトには異なるユースケースがあります。

@DanielRosenwasserのよく知られたシンボルがプロトコルとして使用されます。 たとえば、MapキーがSymbol.match場合、オブジェクトは正規表現のようにはなりません（また、TS組み込みを明示的に使用しなくても、オブジェクトを反復可能にするためにSymbol.iterableキーが必要になる場合があります）。反復可能なタイプ）。

ほぼ5年（

この機能を実装してください。コードを正常に記述できません。

参加者はユースケースで実際の例を提供できますか？

プロトコルの例と、それが今日不可能な理由がわかりません。

これがStringConvertible例です

const intoString = Symbol("intoString")

/**
 * Something that can be converted into a string.
 */
interface StringConvertible {
    [intoString](): string;
}

/**
 * Something that is adorable.
 */
class Dog implements StringConvertible {
    [intoString](): string {
        return "RUFF RUFF";
    }
}

/**
 * <strong i="9">@see</strong> {https://twitter.com/drosenwasser/status/1102337805336768513}
 */
class FontDog implements StringConvertible {
    [intoString](): string {
        return "WOFF WOFF";
    }
}

console.log(new Dog()[intoString]())
console.log(new FontDog()[intoString]())

MappableまたはFunctor例を次に示します（高階型コンストラクターの欠如は別として）：

const map = Symbol("map")

interface Mappable<T> {
    [map]<U>(f: (x: T) => U): Mappable<U>
}

class MyCoolArray<T> extends Array<T> implements Mappable<T> {
    [map]<U>(f: (x: T) => U) {
        return this.map(f) as MyCoolArray<U>;
    }
}

@DanielRosenwasserは、すべてのオブジェクトにインターフェイスがあるか、クラスインスタンスであるか、事前にわかっていると想定しているようです。 最後の例を使用すると、たとえば、 mapを任意のjavascriptオブジェクト（または、少なくとも、任意のシンボルを追加できるタイプのオブジェクト）にインストールできるはずです。これにより、マップ可能になります。

事後にプロパティ（シンボルかどうか）をオブジェクトにインストールすることは、別の機能要求（「拡張プロパティ」または「拡張タイプ」と呼ばれることが多い）の一部です。

それがなければ、シンボルインデックス署名に必要なタイプは、TypeScriptユーザーとしてはほとんど提供されませんよね？ 私が正しく理解していれば、種類はのようなものにする必要がありますunknownまたはちょうどanyやや有用であること。

interface SymbolIndexable {
   [prop: symbol]: any; // ?
}

プロトコルの場合、それは一般的に関数ですが、確かに、それはunknownである可能性があります。

必要なのはtype O = { [k: string]: unknown }に相当する記号（およびbigint）なので、型システムで実際のJSオブジェクト（任意の種類のキーを持つことができるもの）を表すことができます。 後で必要に応じて絞り込むことができますが、JSオブジェクトの基本タイプは基本的に{ [k: string | bigint | symbol | number]: unknown }になります。

ああ、 @ DanielRosenwasserポイントが表示されていると思います。 私は現在、次のようなインターフェースを持つコードを持っています：

export interface Environment<T> {
    [Default](tag: string): Intrinsic<T>;
    [Text]?(text: string): string;
    [tag: string]: Intrinsic<T>;
    // TODO: allow symbol index parameters when typescript gets its shit together
    // [tag: symbol]: Intrinsic<T>;
}

ここで、 Intrinsic<T>は関数型であり、開発者が文字列と同様の環境で独自のシンボルプロパティを定義できるようにしたいのですが、 [Symbol.iterator] 、 [Symbol.species]またはカスタムシンボルプロパティを任意のインターフェイスに設定すると、シンボル付きのインデックス署名により、これらのプロパティを実装するオブジェクトが誤って制限されます。

つまり、シンボルによるインデックス付けの値型をanyよりも具体的にすることはできないということですか？ これを可能にするために、どういうわけかunique symbolとsymbol区別を使用できますか？ インデックス署名を通常のシンボルのデフォルトにし、一意の/既知のシンボルがインデックスタイプをオーバーライドできるようにすることができますか？ タイプセーフでなくても、シンボルインデックスによってプロパティを任意に取得/設定できると便利です。

別の方法は、ユーザーにシンボルプロパティを使用して環境インターフェイスを拡張させることですが、ユーザーがオブジェクトに何でも入力できる限り、これは追加のタイプの安全性を提供しません。

@DanielRosenwasserここに私の生産コードの本当の例。 多くの場所でマップとして再利用され、アトムのキー（ドメイン化された機能）を受け入れる場合がある状態。 現在、シンボルサポートを追加する必要がありますが、多くのエラーが発生します。

とにかく、現在の動作は間違っているES標準と互換性がありません。

シンボルタイプに関して私が持っていたもう1つの深夜の考え。 なぜこれはエラーではないのですか？

const foo = {
  [Symbol.iterator]: 1,
}

JSは、すべてのSymbol.iteratorプロパティがイテレータを返す関数であると想定しており、このオブジェクトがさまざまな場所で渡されると、多くのコードが破損します。 すべてのオブジェクトのシンボルプロパティをグローバルに定義する方法があれば、特定のシンボルインデックス署名を許可すると同時に、グローバルオーバーライドも許可することができます。 タイプセーフでしょ？

また、ここでユースケースが必要になる理由もわかりません。 これはES6の非互換性であり、ES6をラップする言語には存在しないはずです。

過去に、これをこのスレッドで修正する方法についての調査結果を投稿しました。このコードに重要なチェックや機能がない場合は、この説明を続けるよりもコードベースに統合する方が時間がかかるとは思えません。

Typescriptのテストフレームワークや要件がわからず、すべての場合にこれを機能させるためにさまざまなファイルを変更する必要があるかどうかわからないため、プルリクエストを実行しませんでした。

したがって、ここで読み取りと書き込みに時間を費やし続ける前に、機能の追加にかかる時間が短縮されるかどうかを確認してください。 Typescriptにあることについて誰もが不満を言うとは思えません。

それとは別に、一般的な使用例は、値を任意のシンボルにマップする場合です。 または、型指定されていないES6コードとの互換性のため。

これが役立つと思う場所の例を次に示します： https ： eventNameは記号または文字列である可能性があるため、次のように言いたいと思います。

type EventsConfiguration = { [eventName: string | Symbol]: (...args: any[]) => void }

最初の行に。

しかし、私はこれをどのように行うべきかについて何かを誤解しているかもしれません。

単純なユースケースは、苦痛なしには実行できません。

type Dict<T> = {
    [key in PropertyKey]: T;
};

function dict<T>() {
    return Object.create(null) as Dict<T>;
}

const has: <T>(dict: Dict<T>, key: PropertyKey) => boolean = Function.prototype.call.bind(Object.prototype.hasOwnProperty);

function forEach<T>(dict: Dict<T>, callbackfn: (value: T, key: string | symbol, dict: Dict<T>) => void, thisArg?: any) {
    for (const key in dict)
        if (has(dict, key))
            callbackfn.call(thisArg, dict[key], key, dict);
    const symbols = Object.getOwnPropertySymbols(dict);
    for (let i = 0; i < symbols.length; i++) {
        const sym = symbols[i];
        callbackfn.call(thisArg, dict[sym], sym, dict); // err
    }
}

const d = dict<boolean>();
const sym = Symbol('sym');
const bi = 9007199254740991n;

d[1] = true;
d['x'] = true;
d[sym] = false; // definitely PITA
d[bi] = false; // another PITA

forEach(d, (value, key) => console.log(key, value));

また、ここでユースケースが必要になる理由もわかりません。

@neonitこれに対処するためのPRがありますが、私の理解では、この機能が他の型システムとどのように相互作用するかについて微妙な問題があります。 それに対する解決策がないので、私がユースケースを求める理由は、私たちが望むすべての機能に一度に取り組む/集中することができないためです-したがって、ユースケースは、長期を含むいる作業を正当化する必要があります機能のメンテナンス。

実際、ほとんどの人が想像しているユースケースは、想像しているほど簡単には解決されないようです（ @brainkimの回答はこちらhttps://github.com/microsoft/TypeScript/issues/1863#issuecomment-574550587を参照）。または、シンボルプロパティ（https://github.com/microsoft/TypeScript/issues/1863#issuecomment-574538121）またはマップ（https://github.com/microsoft/TypeScript/issues/1863）を介して同様にうまく解決されること＃issuecomment-572733050）。

@ Tyler-Murphyは、制約を記述できないという点で、ここで最良の例を示したと思います。これは、シンボルをサポートするタイプセーフなイベントエミッターのようなものに非常に役立ちます。

したがって、ここで読み取りと書き込みに時間を費やし続ける前に、機能の追加にかかる時間が短縮されるかどうかを確認してください。 Typescriptにあることについて誰もが不満を言うとは思えません。

プロジェクトを維持する必要がない場合、これは常に言いやすいです！ 😄これはあなたにとって役立つことだと理解していますが、それを尊重していただければ幸いです。

これはES6の非互換性です

TypeScriptは実行不可能であるため、簡単に入力できない構造がたくさんあります。 これが不可能だと言っているわけではありませんが、これがこの問題を組み立てる適切な方法だとは思いません。

したがって、インデックス署名としてシンボルキーを追加できないのは、独自の型指定を必要とするグローバルでよく知られているシンボルがあり、シンボルインデックスタイプが必然的に衝突するという事実に起因しているようです。 解決策として、すべての既知のシンボルを表すグローバルモジュール/インターフェイスがある場合はどうなりますか？

const Answerable = Symbol.for("Answerable");
declare global {
  interface KnownSymbols {
    [Answerable](): string  | number;
  }
}

interface MyObject {
  [name: symbol]: boolean;
}

const MySymbol = Symbol.for("MySymbol");
const obj: MyObject = {
  [MySymbol]: true,
};

obj[Answerable] = () => "42";

グローバルKnownSymbolsインターフェイスで追加のプロパティを宣言することにより、すべてのオブジェクトにそのシンボルでインデックスを付けることができ、プロパティの値を未定義/値型に制限できます。 これは、typescriptがES6によって提供されるよく知られた記号の型付けを提供できるようにすることで、すぐに価値を提供します。 イテレータを返す関数ではないオブジェクトにSymbol.iteratorプロパティを追加すると、明らかにエラーになるはずですが、現在typescriptにあるものではありません。 また、既存のオブジェクトに既知のシンボルプロパティを追加するのがはるかに簡単になります。

このグローバルモジュールの使用により、シンボルを任意のキーとしても使用できるようになり、したがってインデックス署名で使用できるようになります。 グローバルな既知のシンボルプロパティをローカルインデックスシグニチャタイプよりも優先するだけです。

この提案を実装することで、インデックス署名タイプを前進させることができますか？

個々のユースケースは関係ありません。 大量のJavaScriptの場合は、TS定義で表現できる必要があります。

しかし、私の理解では、機能が他の型システムとどのように相互作用するかには微妙な問題があります

正確には、「インデックスシグニチャが内部的にどのように機能するかをリファクタリングするので、恐ろしい大きな変更であり、インデックスシグニチャがテンプレート変数を使用しないマップされたタイプとどのように異なるか、または異なるべきかについての問題が発生します」のようなものです。

それは主に、クローズドタイプとオープンタイプの認識に失敗する方法についての議論につながりました。 このコンテキストでは、「閉じた」タイプは、値を拡張できない有限のキーセットを持つタイプになります。 必要に応じて、ある種の正確なタイプのキー。 一方、このコンテキストでの「オープン」タイプは、サブタイプ化されると、より多くのキーを追加できるタイプです（現在のサブタイプ化ルールでは、非常に明示的にインデックス署名があるタイプを除いて、ほとんどすべてのタイプがあります）。 。 インデックスシグニチャはオープンタイプを作成することを意味しますが、マップされたタイプは、クローズドタイプで動作しているかのように大きく関連しています。 ほとんどのコードは、実際には、閉じたオブジェクトタイプと互換性のある構造で記述されているため、これは_通常_十分に機能します。 これが、 flow （閉じたオブジェクトタイプと開いたオブジェクトタイプの明示的な構文を持つ）がデフォルトで閉じたオブジェクトタイプになる理由です。 これは、一般的なインデックスキーで頭に浮かびます。 T extends string場合、 Tはますます幅広いタイプ（ "a"から"a" | "b"からstring ）でインスタンス化されるため、オブジェクト"a" | "b" | ... (every other possible string)からstring自体に切り替えるまで、プロデュースはますます専門化されています。 それが起こると、突然タイプが非常にオープンになり、アクセスするためにすべてのプロパティが存在する可能性がありますが、たとえば、空のオブジェクトをそれに割り当てることは合法になります。 それが構造的に起こることですが、マップされた型のジェネリックを関連付けるとき、それを無視します-ジェネリックのマップされた型キーのstring制約は、すべての可能なキーが存在するかのように本質的に関連付けられます。 これは論理的にはキータイプの単純な分散ベースのビューから得られますが、正しいのはキーが_closed_タイプからのものである場合のみです（多くの場合、インデックスシグネチャを持つタイプが実際に閉じられることはありません！）。 したがって、下位互換性が必要な場合は、 {[x: T]: U}を{[_ in T]: U}と同じように扱うことはできません。ただし、一般的でない場合は{[_ in T]: U}であるため、必要な場合を除きます。 {[x: T]: U}になります。マップされたタイプのキーの分散を処理する方法を調整して、オープンタイプの「エッジ」を適切に考慮します。これは、エコシステムに影響を与える可能性のある、それ自体が興味深い変更です。

かなり：マップされたタイプとインデックスシグネチャが非常に接近しているため、両方をどのように処理するかについて多くの質問がありましたが、まだ満足のいく、または決定的な答えはありません。

個々のユースケースは関係ありません。

これは、丁寧に、純粋な狂気です。 ターネーションでは、その動作を判断するためのユースケースなしで、人々が望む動作を備えた機能を追加しているかどうかをどのように知ることができますか？

私たちはこれらの質問をすることによってここで困難になろうとはしていません。 私たちは文字通り、人々が求めていることを確実に実行しようとしています。 「シンボルを使用したインデックス作成」と思われるものを実装した場合、このスレッドのまったく同じ人が戻ってきて、特定のユースケースに対応していなかったために完全に間違ったと言っただけで、本当に残念です。

あなたは私たちに盲目的に飛ぶように頼んでいます。 しないでください！ 飛行機の行き先を教えてください！

私の悪いことに、私は自分が何を意味するのかをより明確にすることができたでしょう。 TSを介してコードをより正確に記述したいという願望ではなく、実際のコードのユースケースを正当化する必要があると人々が感じているように思えました。

したがって、私がそれを正しく理解している場合、これは主に次の問題に関するものです。

const sym = Symbol();
interface Foo
{
    [sym]: number;
    [s: symbol]: string; // just imagine this would be allowed
}

Foo[sym]はあいまいな型であるため、Typescriptコンパイラはこれを競合と見なします。 文字列についても同じ問題がすでに発生しています。

interface Foo
{
    ['str']: number; // <-- compiler error: not assignable to string index type 'string'
    [s: string]: string;
}

これが文字列インデックスで処理される方法は、文字列キーの一般的な仕様があり、それらのタイプに互換性がない場合、特定の文字列インデックスは許可されないということです。

私はECMA2015のような標準シンボル定義するためのシンボルのために、これは、遍在問題だろうと思いますSymbol.iterator任意のオブジェクトで使用することができますので、デフォルトのタイピングを持っている必要があり、。 彼らは奇妙なことにそれを明らかに持っていません。 少なくとも遊び場では、MDNからSymbol.iterator例を実行することはできません。

事前定義されたシンボル型を追加することが計画されていると仮定すると、事前定義されたシンボルインデックスにはすでに互換性のない型があり、共通の一般型が存在できないか、おそらく必要になるため、一般的な[s: symbol]: SomeType定義は常に無効になります。ほとんど（/ all？）の事前定義されたシンボルキーはfunctionタイプであるため、 functionタイプになります。

一般的なインデックスタイプと特定のインデックスタイプが混在する場合の問題は、コンパイル時に不明な値でオブジェクトにインデックスが付けられた場合のタイプの決定です。 文字列インデックスを使用した上記の例が有効であると想像すると、次のことが可能になります。

const foo: Foo = {str: 42, a: 'one', b: 'two'};
const input: string = getUserInput();
const value = foo[input];

同じ問題がシンボルキーにも当てはまります。 コンパイル時にvalueの正確なタイプを判別することは不可能です。 ユーザーが'str'入力すると、 numberになります。それ以外の場合は、 string （少なくともTypescriptはstringであると想定しますが、 undefinedなる可能性があります）。 これが、この機能がない理由ですか？ value 、定義からのすべての可能な型を含む共用体型（この場合はnumber | string ）を与えることで、これを回避できます。

@Neonitええと、それは実装の進行を妨げる問題ではありませんが、それはまさに私が指摘しようとしている問題の1つです-あなたがやろうとしていることによっては、シンボルインデクサーが答えではないかもしれません。

この機能が実装されている場合、すべてのタイプがこれらのシンボルを使用するわけではないため、ECMAScriptの組み込みシンボルが必ずしもすべてを台無しにするわけではありません。 ただし、よく知られているシンボル（または自分で定義したシンボル）を使用してプロパティを定義するタイプは、シンボルのあまり役に立たないインデックス署名に制限される可能性があります。

これは本当に覚えておくべきことです。「これをマップとして使用したい」と「シンボルを使用してプロトコルを実装したい」のユースケースは、型システムの観点からは互換性がありません。 したがって、そのようなことを念頭に置いている場合は、シンボルインデックスの署名が役に立たない可能性があり、明示的なシンボルプロパティまたはマップを介してより適切に機能する可能性があります。

symbolから組み込みシンボルを差し引いたUserSymbolタイプのようなものはどうですか？ シンボルの性質上、偶発的な衝突が

編集：これについてもっと考えると、よく知られているシンボルは、たまたまSymbolを使用して実装された歩哨です。 目標がオブジェクトのシリアル化またはイントロスペクションでない限り、コードはこれらのセンチネルを他のシンボルとは異なる方法で処理するsymbolタイプからそれらを削除すると、「汎用」シンボルを使用する（ほとんどの）コードがより安全になる可能性

@RyanCavanaughこれが私の飛行計画です。

このような記号をプロパティに使用するシステムがあります。

const X = Symbol.for(":ns/name")

const txMap = {
  [X]: "fly away with me!"
}

transact(txMap) // what's the index signature here?

この場合、 txMapをtransactの型シグネチャに適合させたいと思います。 しかし、私の知る限り、今日これを表現することはできません。 私の場合、 transactは、何を期待すべきかわからないライブラリの一部です。 私はプロパティに対してこのようなことをします。

// please forgive my tardiness but in essence this is how I'm typing "TxMap" for objects
type TxMapNs = { [ns: string]: TxMapLocal }
type TxMapLocal = { [name: string]: string | TxMapNs } // leaf or non leaf

スキーマからtransact適合するタイプのセットを生成し、それを使用できます。 そのために私はこのようなことをし、宣言のマージに依存します。

interface TxMap = {
  [DB_IDENT]: symbol // leaf
  [DB_VALUE_TYPE]?: TxMap // not leaf
  [DB_CARDINALITY]?: TxMap
}

しかし、少なくともシンボルのインデックス署名にフォールバックできればいいのですが、 transactだけがプレーンなJavaScriptオブジェクトに渡されることを期待しています。この場合、グローバルシンボルレジストリのシンボルのみを使用します。 プライベートシンボルは使用していません。

これは少し苦痛だと付け加えておきます。

const x = Symbol.for(":x");
const y = Symbol.for(":x");

type X = { [x]: string };
type Y = { [y]: string };

const a: X = { [x]: "foo" };
const b: Y = { [x]: "foo" }; // not legal
const c: X = { [y]: "foo" }; // not legal
const d: Y = { [y]: "foo" };

TypeScriptが、 Symbol.for関数を介して作成されたシンボルが実際に同じであることを理解できれば、非常にすばらしいでしょう。

これも非常に迷惑です。

function keyword(ns: string, name: string): unique symbol { // not possible, why?
  return Symbol.for(":" + ns + "/" + name)
}

const x: unique symbol = keyword("db", "id") // not possible, why?

type X = {
  [x]: string // not possible, why?
}

その小さなユーティリティ関数で、グローバルシンボルテーブルに規約を適用しましょう。 ただし、 Symbol.for関数を使用して作成された場合でも、 unique symbol返すことはできません。 TypeScriptが物事を行う方法のために、私は特定の解決策を放棄せざるを得ません。 それらは機能しません。 そして、それは悲しいことだと思います。

ESプロキシを使用してオブジェクトをプロキシでラップするファクトリ関数を作成するときに、インデックス値としてsymbolが役立つ別のユースケースに遭遇しました。

この例を見てください：

let original = {
    foo: 'a',
    bar: 'b',
    baz: 1
};

function makeProxy<T extends Object>(source: T) {
    return new Proxy(source, {
        get: function (target, prop, receiver) {
            return target[prop];
        }
    });
}

let proxied = makeProxy(original);

ProxyConstructor型の署名を一致させるにObjectに拡張する必要がありますが、汎用引数にキーが設定されていないため、エラーが発生します。 したがって、型シグネチャを拡張できます。

function makeProxy<T extends Object & { [key: string]: any}>(source: T) {

しかし、 ProxyHandlerのgetの2番目の引数（ prop ）はPropertyKey型であるため、エラーが発生します。これはたまたまPropertyKey 。

したがって、この問題の制限のため、TypeScriptでこれを行う方法がわかりません。

@aaronpowellあなたが直面している問題は何ですか？ 正常に動作していることがわかります。

let original = {
    foo: 'a',
    bar: 'b',
    baz: 1
};

function makeProxy<T extends Object>(source: T) {
    return new Proxy(source, {
        get: function (target, prop, receiver) {
            return target[prop];
        }
    });
}

let proxied = makeProxy(original);

function assertString(s:string){}
function assertNumber(x:number){}

assertString(proxied.foo); // no problem as string
assertNumber(proxied.baz); // no problem as number
console.log(proxied.foobar); // fails as expected: error TS2339: Property 'foobar' does not exist on type '{ foo: string; bar: string; baz: number; }'.

tsconfig.json：

{
  "compilerOptions": {
    "module": "esnext",
    "moduleResolution": "node",
    "target": "es2015"
  }

package.json：

{
  "devDependencies": {
    "typescript": "~3.4.5"
  }
}

@beenotung遊び場でエラーが表示されます：

@aaronpowell tsconfig.jsonの「compilerOptions」で「strict」フラグを有効にすると、エラーが表示されます。

したがって、現在のバージョンのtypescriptコンパイラでは、strictモードをオフにするか、ターゲットをanyキャストする必要があります...

もちろんですが、 anyキャストは実際には理想的ではなく、厳密モードを無効にすると、型安全性の制限が緩和されるだけです。

メッセージを読む次の「解決策」はおそらく「typescriptを無効にする」ことだと思います。

一時的な解決策を探す必要はなく、なぜそれが必要なのかを説明する必要もありません。

これはjavascriptの標準機能なので、typescriptで必要です。

@DanielRosenwasser私のユースケースはます- ProxyHandlerインターフェイスとTypeScriptのルールが一致していないため、プロキシハンドラトラップを正しく入力できません。

問題を示す要約例：

const getValue = (target: object, prop: PropertyKey) => target[prop]; // Error

私の知る限り、エラーを回避しながら、 PropertyKeyが合法的にアクセスできるオブジェクトのみを許可するtargetタイプを作成することは不可能です。

私はTypeScriptの初心者なので、明らかな何かが欠けている場合はご容赦ください。

別のユースケース：呼び出し元が特定のタイプのタグ付き値のマップを提供するために、オブジェクトリテラル構文のコンパクトさの恩恵を受ける方法で（名前の衝突を回避しながら）タイプ{[tag: symbol]: SomeSpecificType}を作成しようとしています。プレーン文字列をタグとして使用するリスク）。

別のユースケース：オブジェクト、シンボル、文字列の両方の列挙可能なすべてのプロパティを反復しようとしています。 私の現在のコードは次のようになります（名前が隠されています）：

type ContextKeyMap = Record<PropertyKey, ContextKeyValue>

function setFromObject(context: Context, object: ContextKeyMap) {
    for (const key in object) {
        if (hasOwn.call(object, key)) context.setKey(key, object[key])
    }

    for (const symbol of Object.getOwnPropertySymbols(object)) {
        if (propertyIsEnumerable.call(object, symbol)) {
            context.setKey(symbol, object[symbol as unknown as string])
        }
    }
}

私はこれを実行できることを強く望んでいます：

type ContextKeyMap = Record<PropertyKey, ContextKeyValue>

function setFromObject(context: Context, object: ContextKeyMap) {
    for (const key in object) {
        if (hasOwn.call(object, key)) context.setKey(key, object[key])
    }

    for (const symbol of Object.getOwnPropertySymbols(object)) {
        if (propertyIsEnumerable.call(object, symbol)) {
            context.setKey(symbol, object[symbol])
        }
    }
}

シンボルを使用したインデックス作成にも問題があります。 私のコードは次のとおりです。

const cacheProp = Symbol.for('[memoize]')

function ensureCache<T extends any>(target: T, reset = false): { [key in keyof T]?: Map<any, any> } {
  if (reset || !target[cacheProp]) {
    Object.defineProperty(target, cacheProp, {
      value: Object.create(null),
      configurable: true,
    })
  }
  return target[cacheProp]
}

私は@aaronpowellによる解決策

const cacheProp = Symbol.for('[memoize]') as any

function ensureCache<T extends Object & { [key: string]: any}>(target: T, reset = false): { [key in keyof T]?: Map<any, any> } {
  if (reset || !target[cacheProp]) {
    Object.defineProperty(target, cacheProp, {
      value: Object.create(null),
      configurable: true,
    })
  }

  return target[cacheProp]
}

symbolからanyキャストするのは、それほど良いことではありません。

他の解決策には本当に感謝しています。

@ahnpnlそのユースケースでは、シンボルよりもWeakMapを使用したほうがよいでしょう。エンジンはそれをより適切に最適化します。つまり、 targetのタイプマップは変更されません。 それでもキャストする必要があるかもしれませんが、キャストは戻り値で生きます。

回避策は、ジェネリック関数を使用して値を割り当てることです...

var theAnswer: symbol = Symbol('secret');
var obj = {} as Record<symbol, number>;
obj[theAnswer] = 42; // Currently error, but should be allowed

Object.assign(obj, {theAnswer: 42}) // allowed

回避策は、ジェネリック関数を使用して値を割り当てることです...

var theAnswer: symbol = Symbol('secret');
var obj = {} as Record<symbol, number>;
obj[theAnswer] = 42; // Currently error, but should be allowed

Object.assign(obj, {theAnswer: 42}) // allowed

同意しません。 これらの3つの線は互いに等しいです：

Object.assign(obj, {theAnswer: 42});
Object.assign(obj, {'theAnswer': 42});
obj['theAnswer'] = 42;

@DanielRosenwasser
私はこのユースケースを持っています。遊び場のリンクでは、マップを使用して問題を解決しましたが、見た目は醜いです。

const system = Symbol('system');
const SomeSytePlugin = Symbol('SomeSytePlugin')

/** I would prefer to have this working in TS */
interface Plugs {
    [key: symbol]: (...args: any) => unknown;
}
const plugins = {
    "user": {} as Plugs,
    [system]: {} as Plugs
}
plugins[system][SomeSytePlugin] = () => console.log('awsome')
plugins[system][SomeSytePlugin](); ....

遊び場リンク

ここで記号を使用すると、文字列を使用するときに発生する可能性のある偶発的な上書きが除外されます。 これにより、システム全体がより堅牢になり、保守が容易になります。

TSで動作し、コードで同じ可読性を持つ代替ソリューションがある場合は、私はすべての耳です。

この問題についての公式の説明はありますか？

回避策は、ジェネリック関数を使用して値を割り当てることです...

var theAnswer: symbol = Symbol('secret');
var obj = {} as Record<symbol, number>;
obj[theAnswer] = 42; // Currently error, but should be allowed

Object.assign(obj, {theAnswer: 42}) // allowed

あなたが探しています

Objet.assign(obj, { [theAnswer]: 42 });

ただし、キャストAFAIKなしでx[theAnswer]を読み戻す方法はありません。以下のコメント2を参照してください。

神の愛のために、これを優先してください。

あなたが探しています

Objet.assign(obj, { [theAnswer]: 42 });

ただし、キャストAFAIKなしでx[theAnswer]を読み戻す方法はありません。

mellonisとMingweiSamuelが指摘しているように、ジェネリック関数を使用した回避策は次のとおりです。

var theAnswer: symbol = Symbol("secret");
var obj = {} as Record<symbol, number>;

obj[theAnswer] = 42; // Not allowed, but should be allowed

Object.assign(obj, { [theAnswer]: 42 }); // allowed

function get<T, K extends keyof T>(object: T, key: K): T[K] {
  return object[key];
}

var value = obj[theAnswer]; // Not allowed, but should be allowed

var value = get(obj, theAnswer); // allowed

5年とインデックスとしてのシンボルはまだ許可されていません

この場合の回避策が見つかりました。一般的ではありませんが、場合によっては機能します。

const SYMKEY = Symbol.for('my-key');

interface MyObject {   // Original object interface
  key: string
}

interface MyObjectExtended extends MyObject {
  [SYMKEY]?: string
}

const myObj: MyObject = {
  'key': 'value'
}

// myObj[SYMKEY] = '???' // Not allowed

function getValue(obj: MyObjectExtended, key: keyof MyObjectExtended): any {
  return obj[key];
}

function setValue(obj: MyObjectExtended, key: keyof MyObjectExtended, value: any): void {
  obj[key] = value
}

setValue(myObj, SYMKEY, 'Hello world');
console.log(getValue(myObj, SYMKEY));

@ james4388あなたの例は

参考： https ：

（見つけたばかりです。私は実際にはTSチームの一員ではありません。）