＃394の重複の可能性

https://github.com/Microsoft/TypeScript/issues/1003#issuecomment-61171048も参照して

@ NoelAbrahams ＃394の複製だとは思いませんが、逆に両方の機能は次のようにかなり補完的です。

 class Model<T> {
    get(prop: memberof T): T[prop];
    set(prop:  memberof T, value: T[prop]): void;
  }

理想的だろう

@fdecampredon

contact.set(Math.random() >= 0.5 ? 'age' : 'name', 13)

この場合はどうすればよいですか？

それは私の問題の最後の段落からのものと多かれ少なかれ同じケースです。 複数の選択肢があると言ったように、エラーを報告するか、 anyに対してT[prop] anyを推測することができます。2番目の解決策はより論理的だと思います

素晴らしい提案。 同意します、それは便利な機能でしょう。

@fdecampredon 、これは重複していると思います。 Danからのmembertypeof提案を含む対応する応答を参照してください。

IMOはすべて、かなり狭いユースケース向けの多くの新しい構文です。

@NoelAbrahamsそれは同じではありません。

• memberof Tは、インスタンスがTインスタンスの有効なプロパティ名を持つ文字列のみである可能性があるタイプを返します。
• T[prop]は、 prop引数/変数で表される文字列で名前が付けられたTのプロパティのタイプを返します。

memberofへのブリッジがあり、そのタイプのpropパラメーターはmemberof T必要があります。

実は、型メタデータに基づいた型推論のシステムをもっと充実させたいと思っています。 しかし、そのような演算子はmemberofと同様に良いスタートです。

これは興味深く、望ましいことです。 TypeScriptはまだ文字列の多いフレームワークではうまく機能せず、これは明らかに大いに役立ちます。

TypeScriptは文字列の多いフレームワークではうまく機能しません

本当。 それでも、これが重複した提案であるという事実は変わりません。

それでも、これは明らかに[文字列の多いフレームワークを入力するのに]大いに役立ちます。

それについてはよくわかりません。 かなり断片的で、上で概説したプロキシオブジェクトパターンにいくらか固有のようです。 ＃1003に沿ったマジックストリングの問題に対して、より包括的なアプローチを望んでいます。

1003は、ゲッターの戻り値の型としてanyを提案しています。 この提案は、値のタイプも検索する方法を追加することで、次のような結果になることを追加します。

declare module ImmutableJS {
  class Map<T> {
    get(prop: memberof T): T[prop];
    set(prop: memberof T, value: T[prop]): Map<T>;
  }
}

@ spion 、＃394のことですか？ さらに読み進めると、次のように表示されます。

戻り値の型を考えましたが、全体的な提案が大きくなりすぎないように省略しました。

これは私の最初の考えでしたが、問題があります。 タイプmemberof T引数が複数ある場合、 membertypeof Tはどれを参照しますか？

get(property: memberof T): membertypeof T;
set(property: memberof T, value: membertypeof T);

これは「私が参照している引数」の問題を解決しますが、 membertypeof名前は間違っているようで、プロパティ名をターゲットにしている演算子のファンではありません。

get(property: memberof T): membertypeof property;
set(property: memberof T, value: membertypeof property);

これはうまくいくと思います。

get(property: memberof T is A): A;
set(property: memberof T is A, value: A)

残念ながら、最後の提案にはまともな可能性があると思いますが、私が素晴らしい解決策を持っているかどうかはわかりません。

OK @ NoelAbrahams ＃394に、これとほぼ同じことを説明しようとしているコメントがありました。
さて、 T[prop]は、おそらくこのコメントのさまざまな提案よりも少しエレガントであり、この問題の提案はおそらくもう少し反省していると思います。
これらの理由から、私はそれが重複として閉じられるべきではないと思います。
しかし、私は問題を書いた人なので、私は偏見があると思います;）。

@fdecampredon 、もっと楽しい：smiley：

@NoelAbrahamsおっと、私はその部分を逃しました。 確かに、それらはほとんど同等です（これは別の汎用パラメーターを導入していないようですが、問題がある場合とない場合があります）

Flowを見てみると、アドホックな型の絞り込みよりも、少し強い型システムと特殊な型の方がエレガントだと思います。

たとえば、 get(prop: string): Contact[prop]で意味するのは、一連の可能なオーバーロードです。

interface Map {
  get(prop : string) : Contact[prop];
}

// is morally equivalent to 

interface Map {
  get(prop : "name") : string;
  get(prop : "age") : number;
}

&型演算子（交差型）が存在すると仮定すると、これは同等の型です。

interface Map {
   get : (prop : "name") => string & (prop : "age") => number;
}

非ジェネリックケースを特別な処理なし（ [prop] ）の型式のみに変換したので、パラメーターの問題に対処できます。

アイデアは、型パラメーターからこの型をいくらか生成することです。 いくつかの特別なダミージェネリック型$MapProperties 、 $Name 、および$Valueを定義して、生成された型を型式のみ（特別な構文なし）で表現し、型チェッカーをヒントにすることができます。何かをすべきだと。

class Map<T> {
   get : $MapProperties<T, (prop : $Name) => $Value>
   set : $MapProperties<T, (prop : $Name, val : $Value) => void>
}

複雑でテンプレートに近い、または貧しい人に依存するタイプのように見えるかもしれませんが、誰かがタイプを値に依存させたい場合は避けられません。

これが役立つもう1つの領域は、型指定されたオブジェクトのプロパティを反復処理することです。

interface Env {
 // pretend this is an actually interesting type
};

var actions = {
  action1: function (env: Env, x: number) : void {},
  action2: function (env: Env, y: string) : void {}
};

// actions has type { action1: (Env, number) => void; action2: (Env, string) => void; }
var env : Env = {};
var boundActions = {};
for (var action in actions) {
  boundActions[action] = actions[action].bind(null, env);
}

// boundActions should have type { action1: (number) => void; action2: (string) => void; }

これらの型は、少なくとも理論的には推測できるはずです（ forループの結果を推測するのに十分な型情報があります）が、おそらくかなりの範囲です。

次のバージョンのreactは、そのアプローチの恩恵を大いに受けることに注意してください。https：//github.com/facebook/react/issues/3398を参照して

https://github.com/Microsoft/TypeScript/issues/1295#issuecomment -64944856のように、文字列が文字列リテラル以外の式によって提供される場合、この機能は停止問題のためにすぐに機能しなくなります。 ただし、これの基本バージョンは、ES6シンボル問題（＃2012）からの学習を使用して実装できますか？

承認されました。

構文の感触をつかむために、これを実験的なブランチで試してみたいと思います。

提案のどのバージョンが実装されるのか疑問に思っていますか？ つまり、 T[prop]は呼び出しサイトで評価され、熱心に具体的な型に置き換えられるのでしょうか、それとも新しい形式の型変数になるのでしょうか。

＃3779で定義されているように、より一般的で冗長性の低い構文に依存する必要があると思います。

interface Map<T> {
  get<A>(prop: $Member<T,A>): A;
  set<A>(prop: $Member<T,A>, value: A): Map<T>;
}

それとも、Aのタイプを推測することはできませんか？

通常の解決策を待っている間に、ImmutableJSとのTS統合を簡単にするための小さなcodegenツールを作成したと言いたいだけです： https ：//www.npmjs.com/package/tsimmutable

また、メンバータイプのソリューションは、ImmutableJSでは機能しない可能性があることに注意してください。

interface Profile {
  firstName: string 
}

interface User {
  profile: Profile  
}

let a: Map<User> = fromJS(/* ... */);
a.get('profile') // Type will be Profile, but the real type is Map<Profile>!

@ s-panferovこのようなものが機能する可能性があります：

interface ImmutableMap<T> {
    get<A extends boolean | number | string>(key : string) : A;
    get<A extends {}>(key : string) : ImmutableMap<A>;
    get<E, A extends Array<any>>(key : string) : ImmutableList<E>;
}

interface Profile {

}

interface User {
    name : string;
    profile : Profile;
}

var map : ImmutableMap<User>;

var name = map.get<string>('name'); // string
var profile = map.get<Profile>('profile'); // ImmutableMap<Profile>

これはDOMノードまたはDateオブジェクトを除外しませんが、不変の構造でそれらを使用することを許可するべきではありません。 https://github.com/facebook/immutable-js/wiki/Converting-from-JS-objects

最善の回避策から徐々に作業する

最初に現在利用可能な最善の回避策から始めて、そこから徐々に解決していくと便利だと思います。

含まれている非プリミティブオブジェクトのプロパティの値を返す関数が必要だとしましょう。

function getProperty<T extends object>(container: T; propertyName: string) {
    return container[propertyName];
}

ここで、戻り値にターゲットプロパティの型を持たせたいので、その型に別のジェネリック型パラメーターを追加できます。

function getProperty<T extends object, P>(container: T; propertyName: string) {
    return <P> container[propertyName];
}

したがって、クラスのユースケースは次のようになります。

class C {
    member: number;
    static member: string;
}

let instance = new C();
let result = getProperty<C, typeof instance.member>(instance, "member");

そして、 resultはタイプnumberを正しく受け取ります。

ただし、呼び出しには「member」への重複した参照があるようです。1つはtypeパラメーターにあり、もう1つはターゲットプロパティ名の文字列表現を常に受け​​取る_literal_文字列です。 この提案のアイデアは、これら2つを、文字列表現のみを受け取る単一の型パラメーターに統合できるというものです。

したがって、ここでは、文字列が_genericパラメーター_としても機能し、これが機能するためにリテラルとして渡される必要があることに注意する必要があります（他の場合は、何らかの形式のランタイムリフレクションが使用可能でない限り、その値を黙って無視できます）。 したがって、セマンティクスを明確にするために、汎用パラメーターと文字列の間の関係を示す何らかの方法が必要です。

function getProperty<T extends object, PName: string = propertyName>(container: T; propertyName: string) {
    return <T[PName]> container[propertyName];
}

そして今、呼び出しは次のようになります：

let instance = new C();
let result = getProperty<C>(instance, "member");

これは内部的に次のように解決されます。

let result = getProperty<C, "member">(instance, "member");

ただし、 Cはmemberという名前のインスタンスと静的プロパティの両方が含まれているため、より種類の多い一般式T[PName]はあいまいです。 ここでの意図は主にインスタンスのプロパティに適用することであるため、提案されたtypeon演算子のようなソリューションを内部で使用できます。これにより、 T[PName]が次のように解釈されるため、セマンティクスも改善される可能性があります。 _value reference_、必ずしもタイプではありません：

function getProperty<T extends object, PName: string = propertyName>(container: T; propertyName: string) {
    return <typeon T[PName]> container[propertyName];
}

（ typeonもインターフェイスをサポートしているため、 Tが互換性のあるインターフェイスタイプである場合にも機能します）

静的プロパティを取得するには、コンストラクター自体を使用して関数を呼び出し、コンストラクターの型をtypeof Cとして渡す必要があります。

let result = getProperty<typeof C>(C, "member"); // Note it is called with the constructor object

（内部的にtypeon (typeof C)はtypeof C解決されるため、これは機能します）
resultは、タイプstring正しく受け取るようになりました。

追加のタイプのプロパティ識別子をサポートするために、これは次のように書き直すことができます。

type PropertyIdentifier = string|number|Symbol;

function getProperty<T extends object, PName: PropertyIdentifier = propertyName>(container: T; propertyName: PropertyIdentifier) {
    return <typeon T[PName]> container[propertyName];
}

したがって、これをサポートするために必要ないくつかの異なる機能があります。

• リテラル値をジェネリックパラメーターとして渡すことができます。
• それらのリテラルが関数の引数の値を受け取ることを許可します。
• より高い種類のジェネリックの形式を許可します。
• より高い種類のジェネリックを介して_generic_タイプのリテラルジェネリックパラメーターを介してプロパティタイプを参照できるようにします。

問題を再考する

それでは、元の回避策に戻りましょう。

function getProperty<T extends object, P>(container: T; propertyName: string) {
    return <P> container[propertyName];
}

この回避策の利点の1つは、直接プロパティだけでなく、ネストされたオブジェクトのプロパティも参照して、より複雑なパス名をサポートするように簡単に拡張できることです。

function getPath<T extends object, P>(container: T; path: string) {
    ... more complex code here ...

    return <P> resultValue;
}

そして今：

class C {
    a: {
        b: {
            c: string[];
        }
    }
}
let instance = new C();
let result = getPath<C, typeof instance.a.b.c>(instance, "a.b.c");

resultは、ここでタイプstring[]を正しく取得します。

問題は、ネストされたパスもサポートする必要があるかどうかです。 入力時にオートコンプリートが利用できない場合、この機能は本当に便利ですか？

これは、別の解決策が可能であり、それが他の方向に機能する可能性があることを示唆しています。 元の回避策に戻る：

function getProperty<T extends object, P>(container: T; propertyName: string) {
    return <P> container[propertyName];
}

これを別の方向から見ると、型参照自体を取得して文字列に変換することができます。

function getProperty<T extends object, P>(container: T; propertyName: string = @typeReferencePathOf(P)) {
    return <P> container[propertyName];
}

@typeReferencePathOfは、概念的にはnameOf似ていますが、汎用パラメーターに適用されます。 受信した型参照typeof instance.member （またはtypeon C.member ）を受け取り、プロパティパスmember抽出し、コンパイル時にリテラル文字列"member"に変換します。時間。 あまり専門化されていない補完的な@typeReferenceOfは、完全な文字列"typeof instance.member"解決されます。

だから今：

getProperty<C, typeof instance.subObject>(instance);

解決します：

getProperty<C, typeof instance.subObject>(instance, "subObject");

そして、 getPath同様の実装：

getPath<C, typeof instance.a.b.c>(instance);

解決します：

getPath<C, typeof instance.a.b.c>(instance, "a.b.c");

@typeReferencePathOf(P)はデフォルト値としてのみ設定されているため、 引数は、必要に応じて手動で指定できます。

getPath<C, SomeTypeWhichIsNotAPath>(instance, "member.someSubMember.AnotherSubmember.data");

2番目のタイプのパラメーターが指定されない場合、 @typeReferencePathOf()はundefined解決されるか、空の文字列""ます。 タイプが提供されたが内部パスがなかった場合、 ""解決されます。

このアプローチの利点：

• より種類の多いジェネリックは必要ありません。
• リテラルをジェネリックパラメーターとして許可する必要はありません。
• ジェネリックスを拡張する必要はありません。
• typeof式を入力するときにオートコンプリートを許可し、コンパイル時に文字列表現から変換する必要がなく、型チェックの既存のメカニズムを使用して検証します。
• ジェネリッククラス内でも使用できます。
• typeonは必要ありません（ただし、サポートできます）。
• 他のシナリオに適用できます。

+1

いいね！ 私はすでに同じ問題に対処するための大きな提案を書き始めましたが、この議論を見つけたので、ここで議論しましょう。

これが私の未提出の問題からの抜粋です：

質問：次の関数は、使用されることになっているコンテキストで使用できるように、.d.tsでどのように宣言する必要がありますか？

function mapValues(obj, fn) {
      return Object.keys(obj)
          .map(key => ({key, value: fn(obj[key], key)}))
          .reduce((res, {key, value}) => (res[key] = value, res), {})
}

この関数（わずかな違いはあります）は、ほとんどすべての一般的な「utils」ライブラリにあります。

野生のmapValuesには2つの異なるユースケースがあります。

a。 _Object-as-a-_ _Dictionary _ここで、プロパティ名は動的であり、値は同じ1つのタイプであり、関数は一般に単形です（このタイプを認識します）

var obj = {'a': 1, 'b': 2, 'c': 3};
var res = mapValues(x, val => val * 5); // {a: 5, b: 10, c: 15}
console.log(res['a']) // 5

b。 _Object-as-a-_ _Record _ここで、各プロパティは独自のタイプを持ち、関数はパラメトリックに多態的です（実装による）

var obj = {a: 123, b: "Hello", c: true};
var res = mapValues(p, val => [val]); // {a: [123], b: ["Hello"], c: [true]}
console.log(res.a[0].toFixed(2)) // "123.00"

現在のTypeScriptでmapValues利用できる最良のインストルメンテーションは、次のとおりです。

declare function mapValues<T1, T2>(
    obj: {[key: string]: T1},
    fn: (arg: T1, key: string) => T2
): {[key: string]: T2};

この署名が_Object-as-a -__ Dictionary _ユースケースに完全に一致することを確認するのは難しくありませんが、_Object-as-a-_の場合に適用すると、型推論の結果がやや驚くべき^1になります。 _Record_が意図されていました。

タイプ{p1: T1, p2: T2, ...pn: Tn}は、すべてのタイプを統合し、レコードの構造に関するすべての情報を効果的に破棄する{[key: string]: T1 | T2 | ... | Tn }強制変換されます。

• 正しくて期待される²は問題ないconsole.log(res.a[0].toFixed(2))はコンパイラによって拒否されます。
• 受け入れられたconsole.log((<number>res['a'][0]).toFixed(2))は、型キャストと任意のプロパティ名の2つの制御されていないエラーが発生しやすい場所があります。

^1、2 —ESからTSに移行するプログラマー向け

この問題に対処する（そして他の問題も解決する）ための可能な手順

1.文字列リテラルタイプを使用して可変個引数レコードを導入します

type Numbers<p extends string> =  { ...p: number };
type NumbersOpt<p extends string> = {...p?: number };
type ABC = "a" | "b" | "c";
type abc = Numbers<ABC> // abc =  {a: number, b: number, c: number} 
type abcOpt = NumbersOpt<ABC> // abcOpt =  {a?: number, b?:number, c?: number}

function toFixedAll<p extends string>(obj: {...p: number}, precision):{...p: string}  {
      var result: {...p: string} = {} as any;
      Object.keys(obj).forEach((p:p) => {
           result[p] = obj[p].toFixed(precision);
      });
      return result;
}

var test = toFixedAll({x:5, y:7}, 3); // { x: "5.00", y: "6.00" },  p inferred as "x"|"y"
console.log(test.y.length) // 4   test.y: string

2.「文字列」を拡張するように制約されている他の正式な型で正式な型に添え字を付けることができます

例：

declare function mapValues<p extends string, T1[p], T2[p]>(
     obj:{...p: T1[p]}, fn:(arg: T1[p]) => T2[p]
): {...p: T2[p]};

3.フォーマルタイプの破棄を許可する

例：

class C<Array<T>> {
     x: T;
}   

var v1: C<string[]>;   // v1.x: string

3つのステップすべてを一緒に書くことができます

declare module Backbone {

  class Model<{...p: T[p]}> {
    get(prop: p): T[p];
    set(prop: p, value: T[p]): void;
  }
}

declare module ImmutableJS {
  class Map<{...p: T[p]}> {
    get(prop: p): T[p];
    set(prop: p, value: T[p]): this;
  }
}

declare function pluck<p extends string, T[p]>(
    arr: Array<{...p:T[p]}>, prop: p
): Array<T[p]> 

構文が@fdecampredonによって提案されたものよりも冗長であることを私は知っています
しかし、元の提案でmapValuesまたはcombineReducersのタイプを表現する方法を想像することはできません。

function combineReducers(reducers) {
  return (state, action) => mapValues(reducers, (reducer, key) => reducer(state[key], action))
}

私の提案では、その宣言は次のようになります。

declare function combineReducers<p extends string, S[p]>(
    reducers: { ...p: (state: S[p], action: Action) => S[p] }
): (state: { ...p: S[p] }, action: Action) => { ...p: S[p] };

元の提案で表現できますか？

@ spion 、 @ fdecampredon ？

@Artazor間違いなく改善。 これで、この機能のベンチマークユースケースを表現するのに十分なようです。

user.idとuser.nameが、それに応じてnumberとstringを含むデータベース列タイプであると仮定します。つまりColumn<number>とColumn<string>

次の関数selectのタイプを記述します。

select({id: user.id, name: user.name})

そしてQuery<{id: number; name: string}>を返します

select<T>({...p: Column<T[p]>}):Query<T>

しかし、それがどのようにチェックされ、推測されるのかはわかりません。 タイプTが存在しないため、問題があるようです。 戻り値の型は、非構造化された形式で表現する必要がありますか？ すなわち

select<T>({...p: Column<T[p]>}):Query<{...p:T[p]}>

@Artazorは質問するのを忘れました、 p extends stringパラメータは本当に必要ですか？

このようなもので十分ではないでしょうか？

select<T[p]>({...p: Column<T[p]>}):Query<{...p:T[p]}>

つまり、 {...p:Column<T[p]>}すべての型変数T [p]

編集：別の質問、これはどのように正しいかどうかをチェックするのですか？

@spion私はあなたの見解を持っています—あなたは私を誤解しました（しかしそれは私のせいです）、 T[p]私はまったく異なることを意味しました、そしてあなたはそのp extends stringを見るでしょう

データ構造の4つのユースケースを考えてみましょう： List 、 Tuple 、 Dictionary 、 Record 。 それらを_概念データ構造_と呼び、次のプロパティで説明します。

JavaScriptでは、これら4つのケースは2つのストレージ形式によって支えられています。a1とa2の場合はArray 、 b1とb2の場合はObjectです。

_注1_ 。 正直なところ、 TupleがArrayに支えられていると言うのは正しくありません。これは、唯一の「真の」タプル型がargumentsオブジェクトの型であるためです。 Arrayはありません。 それにもかかわらず、それらは多かれ少なかれ互換性があり、特に破壊とメタプログラミングへの扉を開くFunction.prototype.applyのコンテキストではそうです。 TypeScriptは、タプルのモデリングに配列も活用します。

_注2_。 任意のキーを持つ辞書の完全な概念は、数十年後にES6 Map形で導入されましたが、 Recordと限定されたDictionaryを統合するというBrendanEichの最初の決定（文字列キーのみ） Object （ obj.propはobj["prop"]と同等）の同じフードの下で、言語全体の中で最も物議を醸す要素になりました（私の意見では）。
これは、JavaScriptセマンティクスの呪いと祝福の両方です。 それは内省を些細なものにし、プログラマーが（気づかなくても！）ほとんどゼロの精神的コストで_programming_レベルと_meta-programming_レベルを自由に切り替えることを奨励します。 スクリプト言語としてのJavaScriptの成功に欠かせない要素だと思います。

今こそ、TypeScriptがこの奇妙なセマンティクスの型を表現する方法を提供する時です。 _プログラミング_レベルで考えると、すべて問題ありません。

ただし、_meta-programming_レベルに切り替えると、_programming_レベルで修正されたものが突然可変になります。 そしてここで、タプルと関数シグニチャの関係を突然認識し、＃5453（Variadic Kinds）のようなものを提案します。これは、実際にはメタプログラミングのニーズのごく一部（ただし非常に重要）のみをカバーします。残りの引数のタイプへのパラメーター：

     function f<T>(a: number, ...args:T) { ... }

    f<[string,boolean]>(1, "A", true);

＃6018も実装される場合、Functionクラスは次のようになります。

declare class Function<This, TArgs, TRes> {
        This::(...args: TArgs): TRes;
        call(self: This, ...args: TArgs): TRes;
        apply(self: This, args: TArgs): TRes;
        // bind needs also formal pattern matching:
        bind<[...TPartial, ...TCurried] = TArgs>(
           self: This, ...args: TPartial): Function<{}, TCurried, TRes> 
}

それは素晴らしいですが、とにかく不完全です。

たとえば、次の関数に正しい型を割り当てたいとします。

function extractAndWrapAll(...args) {
     return args.map(x => [x]);
}

// wrapAll(1,"A",true) === [[1],["A"],[true]]

提案された可変個引数の種類では、署名の種類を変換できません。 ここでは、もっと強力なものが必要です。 実際、（Facebookのフローのように）型を操作できるコンパイル時関数があることが望ましいです。 ただし、これは、TypeScriptの型システムが、次のマイナーアップデートでユーザーランドを壊す大きなリスクなしにエンドプログラマーに公開するのに十分安定している場合にのみ可能になると確信しています。 したがって、完全なメタプログラミングサポートよりも過激ではないものの、実証された問題に対処できるものが必要です。

この問題に対処するために、_objectsignature_の概念を紹介したいと思います。 大まかにどちらかです

1. オブジェクトのプロパティ名のセット、または
2. 辞書のキーのセット、または
3. 配列の数値インデックスのセット
4. タプルの数値位置のセット。

理想的には、次のような配列またはタプルのシグネチャを表すために、整数リテラルタイプと文字列リテラルタイプがあると便利です。

type ZeroToFive = 0 | 1 | 2 | 3 | 4 | 5;
// or
type ZeroToFive = 0 .. 5;   // ZeroToFive extends number (!)

整数リテラルの規則は、文字列リテラルの規則と一致しています。

次に、オブジェクトのレスト/スプレッド構文と完全に一致する署名抽象化構文を導入できます。

{...Props: T }

1つの重要な例外を除いて、ここでPropsは、全称記号の下でバインドされる識別子です。

<Props extends string> {...Props: T }  // every property has type T

<Index extends number> {...Index: T }  // every item has type T  
// the same as T[]

したがって、タイプレキシカルスコープで導入され、タイプの名前としてこのスコープ内のどこでも使用できます。 ただし、その使用法は二重です。rest/ Spreadプロパティ名の代わりに使用すると、オブジェクトシグネチャの抽象化を表し、スタンドアロンタイプを使用すると、文字列（または数値）のサブタイプを表します。

declare class Object {
      static keys<p extends string, q extends p>(object{...q: {}}): p[];
}

そして、これが最も洗練された部分です：_キー依存型_

特別な型構造を紹介します： T for Prop （混乱したT [Prop]ではなくこの構文を使用したい）ここで、Propはオブジェクトの署名の抽象化を保持する型変数の名前です。 例えば<Prop extends string, T for Prop>発表タイプ字句範囲に2つの仮タイプ、 PropおよびTそれは、各特定の値のために知られている場合pのProp独自のタイプTます。

プロパティがProps 、そのタイプがTあるオブジェクトがどこかにあるとは言いません！ 2つのタイプ間の機能依存性のみを紹介します。 タイプTはタイププロップのメンバーと相関関係があり、それだけです！

それは私たちにそのようなものを書く可能性を与えます

function unwrap<P extends string, T for P>(obj:{...P: Maybe<T>}): Maybe<{...P: T}> {
  ...
}

unwrap({a:{value:1}, b:{value:"A"}, c:{value: true}}) === { a: 1, b: "A", c: true }
// here actual parameters will be inferred as 
unwrap<"a"|"b"|"c", {a: number, b: string, c: boolean}>

ただし、2番目のパラメーターはオブジェクトとしてではなく、タイプへの識別子の抽象的なマップとして扱われます。 この観点では、Pが数値のサブタイプである場合、 T for Pを使用して、タプルのタイプの抽象シーケンスを表すことができます（ @JsonFreeman ？）

Tが{...P: .... T .... }内のどこかで使用されている場合、それはそのマップの1つの特定のタイプを表します。

それが私の主なアイデアです。
質問、考え、批判を熱心に待っています-）

そうです、 extends stringは、ある場合には配列（および可変個引数）を考慮に入れ、他の場合には（型としての）文字列定数を考慮に入れることです。 甘い！

どこかにプロパティPropsを持つオブジェクトがあり、そのタイプがTであるとは言いません。 2つのタイプ間の機能依存性のみを紹介します。 タイプTはタイププロップのメンバーと相関関係があり、それだけです！

私はそれを意味していませんでした。それらのタイプはT [p]であり、pでインデックス付けされたタイプの辞書であるためです。 それが良い直感なら、私はそれを維持します。

全体的に見て、構文にはもう少し作業が必要かもしれませんが、一般的な考え方は素晴らしいように見えます。

可変個引数にunwrapを書くことは可能ですか？

編集：気にしないでください、私はあなたが提案した可変個引数の種類への拡張がこれに対処していることに気づきました。

みなさん、こんにちは。
私は自分の問題の1つを解決する方法に戸惑い、この議論を見つけました。
問題は：
RpcManager.call(command:Command):Promise<T>メソッドがあり、使用法は次のようになります。

RpcManager.call(new GetBalance(123)).then((result) => {
 // here I want that result would have a type.
});

私が思う解決策は次のようになります：

interface Command<T> {
    responseType:T;
}

class GetBalance implements Command<number> {
    responseType: number; // somehow this should be avoided. maybe Command should be abstract class.
    constructor(userId:number) {}
}

class RpcManager {
    static call(command:Command):Promise<typeof command.responseType> {
    }
}

or:

class RpcManager {
    static call<T>(command:Command<T>):Promise<T> {
    }
}

これについて何か考えはありますか？

@ antanas-arvaseviciusその例の最後のコードブロックは、あなたが望むことをするはずです。

特定のタスクをどのように実行するかについて、もっと疑問があるようです。 コンパイラのバグを見つけたと思われる場合は、Stack Overflowを使用するか、問題を報告してください。

こんにちは、ライアン、お返事ありがとうございます。
コードの最後のブロックを試しましたが、機能しません。

クイックデモ：

interface Command<T> { }
class MyCommand implements Command<{status:string}> { }
class RPC { static call<T>(command:Command<T>):T { return; } }

let response = RPC.call(new MyCommand());
console.log(response.status);

//output: error TS2339: Property 'status' does not exist on type '{}'.
//tested with: Version 1.9.0-dev.20160222

Stack Overflowを使用しなかったのは残念ですが、この問題に関連していると思いました:)
このトピックに関する新しい問題を開く必要がありますか？

消費されていないジェネリック型パラメーターは、推論が機能しないようにします。 一般に、型宣言に未使用の型パラメーターは意味がないため、絶対に使用しないでください。 Tを消費すると、すべてが正常に機能します。

interface Command<T> { foo: T }
class MyCommand implements Command<{status:string}> { foo: { status: string; } }
class RPC { static call<T>(command:Command<T>):T { return; } }

let response = RPC.call(new MyCommand());
console.log(response.status);

それはすごい！ ありがとうございました！
型パラメーターをジェネリック型の中に配置できるとは思っていませんでした。
TSがそれを抽出します。
2016年2月22日午後11時56分、「RyanCavanaugh」 [email protected]は次のように書いています。

消費されていないジェネリック型パラメーターは、推論が機能しないようにします。 に
一般的に、型に未使用の型パラメータを含めるべきではありません。
彼らは無意味なので宣言。 Tを消費すると、すべてが
作品：

インターフェイスコマンド{foo：T} classMyCommandはCommand <{status：string}>を実装します{foo：{status：string; }} class RPC {静的呼び出し（コマンド：コマンド）：T {return; }}
応答= RPC.call（new MyCommand（））;
console.log（response.status）;

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/1295#issuecomment -187404245
。

@ antanas-arvasevicius RPCスタイルのAPIを作成している場合、役立つと思われるドキュメントがいくつかあります： https ：

上記のアプローチは次のようです。

• 非常に複雑です。
• コード内の文字列の使用に取り組まないでください。 stringは、「すべての参照を検索」することも、リファクタリングすることもできません（名前の変更など）。
• 一部は「第1レベル」のプロパティのみをサポートし、より複雑な式はサポートしません（一部のフレームワークでサポートされています）。

これは、C＃式ツリーに触発された別のアイデアです。 これは大まかなアイデアであり、完全に考え抜かれたものではありません。 構文はひどいです。 これが誰かを刺激するかどうかを見たいだけです。

式を表す特別な種類の文字列があるとします。
それをtype Expr<T, U> = stringと呼びましょう。
ここで、 Tは開始オブジェクトタイプであり、 Uは結果タイプです。

タイプT 1つのパラメーターを受け取り、そのパラメーターに対してメンバーアクセスを実行するラムダを使用して、 Expr<T,U>インスタンスを作成できると仮定します。
例： person => person.address.city 。
これが発生すると、ラムダ全体が、パラメーターへのアクセスが含まれている文字列（この場合は"address.city" ）にコンパイルされます。

代わりにプレーンな文字列を使用できます。これはExpr<any, any>ます。

この特別なExprタイプを言語に含めると、次のようなことが可能になります。

function pluck<T, U>(array: T[], prop: Expr<T, U>): U[];

let numbers = pluck([{x: 1}, {x: 2}], p => p.x);  // number[]
// compiles to:
// let numbers = pluck([..], "x");

これは基本的に、C＃で式が使用される目的の限定された形式です。
これを洗練して、どこか面白いところに導くことができると思いますか？

@fdecampredon @RyanCavanaugh

_（ @ jods4-申し訳ありませんが、ここであなたの提案に返信していません。コメントで「埋もれて」いないことを願っています）_

この機能の名前（「タイププロパティタイプ」）は非常にわかりにくく、理解するのが非常に難しいと思います。 ここで説明されている概念が何であるか、そもそもそれが何を意味するのかを理解することすら困難でした。

まず、すべてのタイプにプロパティがあるわけではありません。 undefinedとnullはそうではありません（これらは型システムへの最近の追加にすぎませんが）。 number 、 string 、 booleanようなプリミティブは、プロパティによってインデックス付けされることはめったにありません（たとえば、2 ["prop"]？これは機能しているように見えますが、ほとんどの場合間違いです）

文字列リテラル値を使用して、この問題のます。 ここでのトピックは、新しい「タイプ」の導入に関するものではなく、文字列変数または関数パラメーターを使用して既存のタイプを参照する非常に特殊な方法であり、値はコンパイル時に認識されている必要があります。

特定のユースケースのコンテキストの外で、これができるだけ簡単に説明および例示されていれば、非常に有益でした。

interface MyInterface {
  prop1: number;
  prop2: string;
}

let prop1Name = "prop1";
type Prop1Type = MyInterface[prop1Name]; // Prop1Type is now 'number'

let prop2Name = "prop2";
type Prop2Type = MyInterface[prop2Name]; // Prop2Type is now 'string'

let prop3Name = "prop3";
type NonExistingPropType = MyInterface[prop3Name]; // Compilation error: property 'prop3' does not exist on 'MyInterface'.

let randomString = createRandomString();
type NotAvailablePropType = MyInterface[randomString]; // Compilation error: value of 'randomString' is not known at compile time.

_Edit：これを正しく実装するには、コンパイラは、変数に割り当てられた文字列が、初期化されたポイントと型式で参照されたポイントの間で変更されてい必要があるようです。 これはとても簡単ではないと思いますか？ 実行時の動作に関するこの仮定は常に成り立ちますか？_

_編集2：おそらくこれは変数と一緒に使用した場合にconstのみ機能しますか？_

文字列リテラルが関数またはメソッドのパラメータに渡されるという非常に特殊なケースでのみプロパティ参照を許可することが本来の意図であったかどうかはわかりませんか？ 例えば

function func(someString: string): MyInterface[someString] {
  ..
}

let x = func("prop"); // x gets the type of MyInterface.prop

私はこれを当初の意図を超えて一般化しましたか？

関数の引数が文字列リテラルではない場合、つまりコンパイル時に不明な場合、これはどのように処理されますか？ 例えば

let x = func(getRandomString()); // What type if inferred for 'x' here?

エラーになりますか、それともデフォルトでanyますか？

（追記：これが本当に意図されていた場合は、この問題の名前を文字列リテラル関数またはメソッド引数によるインターフェイスプロパティタイプ参照に変更することをお勧めし

これは、この機能を有効にするために必要なものを示す簡単なベンチマークの例（説明には十分です）です。

この関数のタイプを記述します。これは次のとおりです。

• promiseフィールドを含むオブジェクトを受け取り、
• 同じオブジェクトを返しますが、すべてのフィールドが解決され、各フィールドは適切なタイプになります。

function awaitObject(obj) {
  var result = {};
  var wait = Object.keys(obj)
    .map(key => obj[key].then(val => result[key] = val));
  return Promise.all(wait).then(_ => result)
}

次のオブジェクトで呼び出された場合：

var res = awaitObject({a: Promise.resolve(5), b: Promise.resolve("5")})

結果resはタイプ{a: number; b: string}必要があります

この機能（@Artazorによって完全に具体化されている）を使用すると、署名は次のようになります。

awaitObject<p, T[p]>(obj: {...p: Promise<T[p]>}):Promise<{...p: T[p]}>

編集：上記の戻り値の型を修正しました。 Promise<...>がありません

@spion

例を提供していただきありがとうございますが、ここでは、合理的で簡潔な仕様と、実際のアプリケーションから_切り離された_一連の明確な縮小例を見つけ、これがどのように機能するかについてのセマンティクスとさまざまなエッジケースを強調しようとしています。次のような基本的なものでも：

function func<T extends object>(name: string): T[name] {
 ...
}

1. 効果的で説明的なタイトルを提供するための努力はほとんどありませんでした（「タイププロパティタイプ」は紛らわしく、この機能の説明的な名前ではありません。これは実際には特定のタイプではなく、タイプ参照に関するものです）。 私の最も提案されたタイトルは、_文字列リテラル関数またはメソッド引数によるインターフェイスプロパティタイプの参照_でした（これの範囲を誤解していなかったと仮定します）。
2. nameがコンパイル時に不明、null、または未定義の場合、たとえばfunc<MyType>(getRandomString()) 、 func<MyType>(undefined)場合、どうなるかについて明確な言及はありません。
3. Tがnumberやnullようなプリミティブ型である場合に何が起こるかについての明確な言及はありません
4. これが関数にのみ適用されるかどうか、およびT[name]を関数本体で使用できるかどうかについての明確な詳細は提供されていません。 その場合、 nameが関数本体で再割り当てされ、コンパイル時にその値がわからなくなった場合はどうなりますか？
5. 構文の実際の仕様はありません。たとえば、 T["propName"]またはT[propName] 、それ自体でも機能しますか？ パラメータや変数への参照がなければ、つまり、便利かもしれません！
6. T[name]を他のパラメーターで使用できる場合、または関数スコープの外で使用できる場合は、言及も議論もありません。

function func<T extends object>(name: string, val: T[name]) {
 ...
}

type A = { abcd: number };
const name = "abcd";
let x: A[name]; // Type of 'x' resolves to 'number'

_7。 追加の汎用パラメーターとtypeofを使用した比較的単純な回避策についての実際の議論はありません（言及されましたが、機能がすでに受け入れられてから比較的遅れています）。

function get<T, V>(obj: T, propName: string): V {
    return obj[propName];
}

type MyType = { abcd: number };
let x: MyType  = { abcd: 12 };

let result = get<MyType, typeof x.abcd>(x, "abcd"); // Type of 'result' is 'number'

結論：ここには実際の提案はなく、一連のユースケースのデモンストレーションのみがあります。 これがTypeScriptチームによって受け入れられ、さらには前向きな関心を集めたことに驚いています。そうでなければ、これが彼らの基準に達するとは思わないからです。 ここで少し厳しく聞こえるかもしれませんが（私の典型ではありません）、申し訳ありませんが、私の批判は個人的なものでも、特定の個人に向けられたものでもありません。

メタプログラミングの観点から、本当にそこまで行きたいですか？

JSは動的言語であり、コードは任意の方法でオブジェクトを操作できます。
型システムでモデル化できるものには限界があり、TSではモデル化できない関数を簡単に思い付くことができます。
問題はむしろ、どこまで行くことが合理的で有用かということです。

@spionの最後の例（ awaitObject ）は同時に：

• 言語の観点からは_非常に複雑_（ここでは@malibuziosに同意します）。
• 適用性の点で_非常に狭い_。 その例は特定の制約を選択し、うまく一般化されていません。

ところで@spionあなたはあなたの例の戻り値の型を正しく取得しませんでした...それはPromise返します。

_.pluckなどのフィールドを表す文字列を受け取るAPIの入力に関する元の問題とはかけ離れています。
これらのAPIは一般的であり、それほど複雑ではないため、サポートする必要があります。 そのために{ ...p: T[p] }ようなメタモデルは必要ありません。
OPにはいくつかの例がありますが、問題の名前の私のコメントにはAureliaからの例がいくつかあります。
別のアプローチでこれらのユースケースをカバーできます。考えられるアイデアについては、上記の私のコメントを参照し

@ jods4それはまったく狭くありません。 現時点では型システムでモデル化することが不可能な多くのことに使用できます。 TS型システムで最後に欠けている大きな部品の1つだと思います。 @Artazor https://github.com/Microsoft/TypeScript/issues/1295#issuecomment -177287714による上記の実世界の例はたくさんあり

これはbluebirdのawaitObjectです。 その本当の方法。 タイプは現在役に立たない。

より一般的な解決策の方が良いでしょう。 単純な場合と複雑な場合の両方で機能します。 不十分なソリューションはケースの半分に欠けていることがわかり、将来、より一般的なソリューションを採用する必要がある場合、互換性の問題を簡単に引き起こします。

はい、さらに多くの作業が必要ですが、 @ Artazorは、これまで考え

もっと良い名前が必要かもしれません。試してみますが、通常はこれらのことを正しく理解していません。 「オブジェクトジェネリック」はどうですか？

@spion 、

awaitObject<p,T[p]>(obj: {...p:Promise<T[p]>}): Promise<{...p:T[p]}>

（出力署名のPromiseを見逃しました）
-）

@ jods4 、
{ ...p: T[p] }が解決策である現実の問題はたくさんあります。 名前を付けるには：react + flux / redux

@spion @Artazor
これを正確に指定するのが非常に複雑になっているのではないかと心配しています。

この問題の背後にある動機は漂っています。 もともとは、オブジェクトフィールドを示す文字列を受け入れるAPIをサポートすることでした。 現在は、オブジェクトをマップまたはレコードとして非常に動的に使用するAPIについて主に説明しています。 1つの石で2羽の鳥を殺すことができれば、私はそれですべてだということに注意してください。

文字列の問題を処理するAPIに戻ると、私の意見ではT[p]は完全な解決策ではありません（理由は前に述べました）。

_正しさのために_ awaitObjectは、Promise以外のプロパティも受け入れる必要があります。少なくとも、Bluebird propsは受け入れます。 だから今私たちは持っています：

awaitObject<p,T[p]>(obj: { ...p: T[p] | Promise<T[p]> }): Promise<T>

この表記が機能することを期待しているため、戻り値の型をPromise<T>に変更しました。
他のオーバーロードがあります。たとえば、そのようなオブジェクトに対してPromiseを使用するものです（その署名はさらに楽しいです）。 つまり、 { ...p }表記は、他のどのタイプよりも一致が悪いと見なす必要があります。

これらすべてを指定するのは大変な作業になります。 これを推し進めたいのなら、次のステップだと思います。

@spion @ jods4

この機能はジェネリックスに関するものではなく、より高種類のポリモーフィック型に関するものでもありません。 これは、（以下で説明するいくつかの「高度な」拡張機能を備えた）包含型を介してプロパティの型を参照するための単なる構文であり、概念的にはtypeofからそれほど遠くありません。 例：

type MyType = { abcd: number };
let y: MyType["abcd"]; // Technically this could also be written as MyType.abcd

今比較してください：

type MyType = { abcd: number };
let x: MyType;

let y: typeof x.abcd;

typeofとの主な違いは2つあります。 typeofとは異なり、これはインスタンスではなく型（少なくとも非プリミティブ型、ここでは省略されることが多い事実）に適用されます。 さらに（これは重要なことです）、リテラル文字列定数（コンパイル時に認識されている必要があります）をプロパティパス記述子およびジェネリックとして使用することをサポートするように拡張されました。

const propName = "abcd";
let y: MyType[propName];
// Or with a generic parameter:
let y: T[propName];

ただし、技術的には、 typeof拡張して、文字列リテラルもサポートすることもできます（これには、 xがジェネリック型である場合も含まれます）。

let x: MyType;
const propName = "abcd";
let y: typeof x[propName];

また、この拡張機能を使用して、ここでいくつかのターゲットケースを解決することもできます。

function get<T>(propName: string, obj: T): typeof obj[propName]

ただし、 typeofは、無期限のネストレベルをサポートするため、より強力です。

let y: typeof x.prop.childProp.deeperChildProp

そして、これは1つのレベルだけになります。 つまり、（私が知る限り）サポートする予定はありません：

let y: MyType["prop"]["childProp"]["deeperChildProp"];
// Or alternatively
let y: MyType["prop.childProp.deeperChildProp"];

この提案の範囲（あいまいさのレベルでの提案とさえ言えば）は狭すぎると思います。 それは特定の問題を解決するのに役立つかもしれません（代替の解決策があるかもしれませんが）、それは多くの人々をそれを促進することに非常に熱心にさせるようです。 ただし、言語からの貴重な構文も消費しています。 より広範な計画と設計指向のアプローチがなければ、この日付の時点で明確な仕様すら持っていないものを急いで導入することは賢明ではないようです。

_編集：コード例のいくつかの明らかな間違いを修正しました_

typeof代替案について少し調べました。

typeof x["abcd"]とtypeof x[42]将来の言語サポートが承認され、現在開発中の＃6606に分類されます（実装が機能しています）。

これは半分の道のりです。 これらを配置すると、残りはいくつかの段階で実行できます。

（1）型式のプロパティ指定子として、文字列リテラル定数（または数値定数-タプルに役立つ可能性がありますか？）のサポートを追加します。例：

let x: MyType;
const propName = "abcd";
let y: typeof x[propName];

（2）これらの指定子をジェネリック型に適用できるようにする

let x: T; // Where T should extend 'object'
const propName = "abcd";
let y: typeof x[propName];

（3）これらの指定子が渡されることを許可し、実際には関数の引数を介して参照を「インスタンス化」します（ typeof list[0]が計画されているため、 pluckようなより複雑なケースをカバーできると思います：

function get<T extends object>(obj: T, propertyName: string): typeof obj[propertyName];
function pluck<T extends object>(list: Array<T>, propertyName: string): Array<typeof list[0][propertyName]>;

（ここのobjectタイプは＃1809で提案されたものです）

より強力ですが（たとえば、 typeof obj[propName][nestedPropName]サポートする場合があります）、この代替アプローチがここで説明するすべてのケースをカバーしない可能性があります。 これでは処理できないと思われる例があれば教えてください（オブジェクトインスタンスがまったく渡されない場合が頭に浮かぶシナリオの1つですが、現時点では、このようなケースを想像するのは難しいです。それは可能だと思いますが、それは必要でしょう）。

_編集：コードのいくつかの間違いを修正しました_

@malibuzios
いくつかの考え：

• これによりAPI定義が修正されますが、呼び出し元には役立ちません。 コールサイトには、まだ何らかのnameofまたはExpressionが必要です。
• .d.ts定義で機能しますが、通常、静的に推測したり、TS関数/実装で検証したりすることはできません。

考えれば考えるほど、 Expression<T, U>はそのような種類のAPIのソリューションのように見えます。 コールサイトの問題、結果の入力を修正し、実装で推測可能+検証可能にすることができます。

@ jods4

上記のコメントの方法で、 pluckは式で実装できるとおっしゃいました。 以前はC＃に精通していましたが、実際に実験したことはなかったので、現時点ではC＃についてあまりよく理解していないことを認めます。

とにかく、TypeScriptが_type引数推論_をサポートしていることを述べたかったので、 pluckを使用する代わりに、 mapを使用して同じ結果を得ることができ、ジェネリックパラメーターを指定する必要さえありません（それは推測されます）そしてまた完全な型のチェックと完了を与えるでしょう：

let x = [{name: "John", age: 34}, {name: "Mary", age: 53}];

let result = x.map(obj => obj.name);
// 'result' is ["John", "Mary"] and its type inferred as 'string[]' 

map （デモンストレーション用に非常に簡略化されています）が次のように宣言されている場合

map<U>(mapFunc: (value: T) => U): U[];

この同じ推論パターンを「トリック」として使用して、任意のラムダ（呼び出す必要さえない）の結果を関数に渡し、その戻り値の型を関数に設定できます。

function thisIsATrick<T, U>(obj: T, onlyPassedToInferTheReturnType: () => U): U {
   return;
}

let x = {name: "John", age: 34};

let result = thisIsATrick(x, () => x.age) // Result inferred as 'number' 

_編集：物自体だけでなく、ここでラムダで渡すのはばかげているように見えるかもしれません！ ただし、ネストされたオブジェクト（ x.prop.Childprop ）のようなより複雑なケースでは、エラーになる可能性のある未定義またはnullの参照が存在する可能性があります。 必ずしも呼び出されるとは限らないラムダに含めることで、それを回避できます。_

ここで説明するいくつかのユースケースについては、あまり詳しくないことを認めます。 個人的には、プロパティ名を文字列として受け取る関数を呼び出す必要性を感じたことはありません。 ラムダ（あなたが説明する利点も当てはまる）を型引数インターフェースと組み合わせて渡すことは、通常、多くの一般的な問題を解決するのに十分です。

私がtypeof代替アプローチを提案した理由は、ほとんどの場合、それがほぼ同じユースケースをカバーし、人々がここで説明するものと同じ機能を提供するように思われるためです。 自分で使用しますか？ わからない、本当の必要性を感じたことはありません（アンダースコアのような外部ライブラリをほとんど使用しないということかもしれません。ほとんどの場合、必要に応じて自分でユーティリティ関数を開発します）。

@malibuzios確かに、 pluckはラムダ+ map組み込まれているので少しばかげています。

このコメントでは、すべて文字列を受け取る5つの異なるAPIを提供します。これらはすべて、変更の監視に接続されています。

@ jods4など

＃6606が完了すると、ステージ1を実装するだけで（定数文字列リテラルをプロパティ指定子として使用できるようにする）、ここで必要な機能の一部を実現できますが、それほどエレガントではありません（必要になる場合があります）。定数として宣言され、ステートメントが追加されるプロパティ名）。

function observeProperty<T, U>(obj: T, propName: string ): Subscriber<U> {
    ....
}

let x = { name: "John", age: 42 };

const propName = "age";
observeProperty<typeof x, typeof x[propName]>(x, propName);

ただし、これを実装するための労力は、ステージ2および3を実装するよりも大幅に少ない可能性があります（わかりませんが、1はすでに＃6606でカバーされている可能性があります）。 ステージ2が実装されている場合、これはxがジェネリック型である場合もカバーします（ただし、それが本当に必要かどうかはわかりません）。

編集：外部定数を使用してプロパティ名を2回書き込んだだけでなく、入力を減らすだけでなく、名前が常に一致するようにするためですが、これは「名前の変更」や「すべて検索」などのツールでは使用できません。参照」、これは深刻な欠点であることがわかりました。

@ jods4文字列を使用しないより良い解決策をまだ探しています。 nameofとそのバリアントで何ができるかを考えてみます。

ここに別のアイデアがあります。

文字列リテラルはすでに型としてサポートされているため、たとえば、次のように書くことができます。

let x: "HELLO"; 

関数に渡されたリテラル文字列をジェネリック特殊化の形式として表示できます

（_Edit：これらの例は、 sが関数本体で不変になるように修正されましたが、この時点ではconstはパラメーター位置でサポートされていません（ readonlyについてはわかりません）しかし）._）：

function func(const s: string)

s関連付けられたstringパラメータタイプは、ここでは暗黙のジェネリックと見なすことができます（文字列リテラルに特化できるため）。 わかりやすくするために、より明確に記述します（ただし、本当に必要かどうかはわかりません）。

function func<S extends string>(const s: S)
func("TEST");

内部的に次のことに特化できます。

function func(s: "TEST")

そして今、これはプロパティ名を「渡す」ための代替方法として使用できます。これは、ここでセマンティクスをより適切に捉えていると思います。

function observeProperty<T, S extends string>(obj: T, const propName: S): Subscriber<T[S]>

x = { name: "John",  age: 33};

observeProperty(x, nameof(x.age))

T[S] 、 TとS両方が汎用パラメーターです。 ランタイム要素とタイプスコープ要素を混在させるよりも、タイプ位置で2つのタイプを組み合わせる方が自然なようです（例： T[someString] ）。

_編集：不変の文字列パラメータタイプを持つように例を書き直しました。_

最新バージョンではなくTS 1.8.7を使用しているので、

const x = "Hello";

x型は、リテラル型"Hello" （つまり、 x: "Hello" ）としてすでに推測されており、これは非常に理にかなっています（＃6554を参照）。

したがって、当然のことながら、パラメーターをconstとして定義する方法があった場合（またはreadonlyも機能するでしょうか？）：

function func<S extends string>(const s: S): S

それから私はこれが成り立つと信じています：

let result = func("abcd"); // type of 'result' inferred as the literal type "abcd"

これのいくつかはかなり新しく、最近の言語機能に依存しているので、私はそれをできるだけ明確に要約しようとします：

（1） const （そしておそらくreadonlyも？）文字列変数がコンパイル時に既知の値を受け取ると、変数は自動的に同じ値を持つリテラル型を受け取ります（これは1.8.xでは発生しない最近の動作だと思います）。

const x = "ABCD";

xタイプは、 stringではなく"ABCD"であると推測されます！たとえば、これをx: "ABCD"ます。

（2） readonly関数パラメーターが許可されている場合、ジェネリック型のreadonlyパラメーターは、パラメーターが不変であるため、引数として受け取ったときにその型を文字列リテラルに自然に特殊化します。

function func<S extends string>(readonly str: S);
func("ABCD");

ここで、 Sは、 stringではなく、タイプ"ABCD"に解決されています。

ただし、 strパラメーターが不変でない場合、コンパイラーはそれが関数の本体で再割り当てされないことを保証できません。したがって、推測される型はstringます。

function func<S extends string>(str: S) {
    str = "DCBA"; // This may happen
}

func("ABCD");

（3）これを利用して、元の提案を変更して、プロパティ指定子がタイプへの参照になるようにすることができます。これは、 string導関数になるように制約する必要があります（場合によっては、ランタイムエンティティではなく、シングルトンリテラルタイプのみに制限するのが適切な場合もありますが、現在、それを行う方法は実際にはありません。

function get<T extends object, S extends string>(obj: T, readonly propName: S): T[S]

TypeScriptは型引数の推論をサポートしているため、これを呼び出すには、型引数を明示的に指定する必要はありません。

let x = { name: "John", age: 42 };

get(x, "age"); // result type is inferred to be 'number'
// or for stronger type safety:
get(x, nameof(x.age)); // result type is inferred to be 'number'

_編集：いくつかのスペルとコードの間違いを修正しました。_
_注：この変更されたアプローチの一般化および拡張バージョンも＃7730で追跡されるようになりました。_

これは、@ Raynosとの話し合いで出てきた、タイププロパティタイプ（または最近呼んでいる「インデックス付きジェネリック」）の別の使用法です。

配列については、すでに次の一般的なチェッカーを作成できます。

function tArray<T>(f:(t:any) => t is T) {
    return function (a:any): a is Array<T> {
        if (!Array.isArray(a)) return false;
        for (var k = 0; k < a.length; ++k)
            if (!f(a[k])) return false;
        return true;
    }
}

function tNumber(n:any): n is number {
    return typeof n === 'number'
}
var isArrayOfNumber = tArray(tNumber)

function test(x: {}) {
    if (isArrayOfNumber(x)) {
        return x[x.length - 1].toFixed(2); // this type checks
    }
}

ジェネリックスのインデックスを作成すると、オブジェクトの一般的なチェッカーを作成することもできます。

function tObject<p, T[p]>(checker: {...p: (t:any) => t is T[p]}) {
  return function(obj: any): obj is {...p: T[p] } {
    for (var key in checker) if (!checker[key](obj[key])) return false;
    return true;
  }
}

これは、文字列、数値、ブール値、null、および未定義のプリミティブチェッカーと一緒に使用すると、次のように記述できます。

var isTodoList = tObject({
  items: tArray(tObject({text: tString, completed: tBoolean})),
  showCompleted: tBoolean
})

同時に、適切なランタイムチェッカーとコンパイル時の型ガードを使用して結果を取得します:)

誰かがこれについてまだ何か仕事をしたことがありますか、それとも誰かのレーダーに乗っていますか？ これは、 lodashやramdaなど、多くのデータベースインターフェイスなど、タイピングを使用できる標準ライブラリの数を大幅に改善するものです。

@malibuzios私はあなたが@Artazorの提案に近づいていると信じて:)

あなたの懸念に対処するには：

function func<S extends string>(readonly str: S): T[str] {
 ...
}

これは

function func<S extends string, T[S]>(str: S):T[S] { }

このように、次のコマンドで呼び出されると、名前は最も具体的な型（文字列定数型）にロックされます。

func("test")

タイプSは"test" （ stringはありません）。 そのため、 str別の値を再割り当てすることはできません。 あなたがそれを試した場合、例えば

str = "other"

コンパイラはエラーを生成する可能性があります（分散の健全性の問題がない限り;））

1つのプロパティの型を取得するだけでなく、任意のスーパー型の型を取得するオプションが必要です。

したがって、私の提案は、次の構文を追加することです。 T[prop]だけでなく、構文T[...props]を追加したいと思います。 ここで、 propsはTのメンバーの配列である必要があります。 そして、結果の型は、のスーパータイプであるTのメンバーとTで定義されたprops 。

node.jsで人気のあるORMであるSequelizeで非常に役立つと思います。 セキュリティ上の理由とパフォーマンス上の理由から、使用する必要のあるテーブルの属性をクエリすることをお勧めします。 それはしばしばタイプのスーパータイプを意味します。

interface IUser {
    id: string;
    name: string;
    email: string;
    createdAt: string;
    updatedAt: string;
    password: string;
    // ...
}

interface Options<T> {
     attributes: (memberof T)[];
}

interface Model<IInstance> {
     findOne(options: Options<IInstance>): IInstance[...options.attributes];
}

declare namespace DbContext {
   define<T>(): Model<T>;
}

const Users = DbContext.define<IUser>({
   id: { type: DbContext.STRING(50), allowNull: false },
   // ...
});

const user = Users.findOne({
    attributes: ['id', 'email', 'name'],
    where: {
        id: 1,
    }
});

user.id
user.email
user.name

user.password // error
user.createdAt // error
user.updatedAt // error

（私の例では、期待どおりの演算子memberofと、 typeof options.attributesと同じ式options.attributesが含まれていますが、 typeof演算子は、型を予期する位置にあるため、この場合は冗長です。）

誰も主張しないなら、私はこれに取り組み始めました。

関数内の型の安全性についてどう思いますか？つまり、returnステートメントが戻り値の型に割り当て可能なものを返すようにしますか？

interface A {
     a: string;
}
function f(p: string): A[p] {
    return 'aaa'; // This is string, but can we ensure it is the intended A[p] ?
}

また、ここで使用されている「プロパティタイプ」という名前は少し間違っているようです。 これは、タイプにプロパティがあり、ほぼすべてのタイプにプロパティがあることを示しています。

「プロパティ参照型」はどうですか？

関数内の型安全性についてどう思いますか

私のブレインストーミング：

let a: A;
function f(p: string): A[p] {
  let x = a[p]; // typeof A[p], only when:
  // 1. p is directly referencing function argument
  // 2. function return type is Property Reference Type

  p = "abc"; // not allowed to assign a new value when p is used on Property Reference Type

  return x; // x is A[p], so okay
}

そして、戻り行の通常の文字列を禁止します。

@malibuziosのアイデアの問題は、推測できない場合に備えてすべてのジェネリックを指定する必要があることです。これは、ウイルスやコードベースの汚染に

https://github.com/Microsoft/TypeScript/issues/1295#issuecomment -239653337に関するTSチームからのコメントはあり

@RyanCavanaugh @mhegazyなど？

名前に関しては、この機能（少なくとも@Artazorが提案した形式）を「インデックス付きジェネリック」と呼び始めました。

別の観点からの解決策は、この問題に対するものである可能性があります。 すでに持ってきているかどうかはわかりませんが、長いスレッドです。 文字列の一般的な提案を作成して、インデックス署名を拡張できます。 文字列リテラルはインデクサータイプに使用できるため、これらを同等にすることができます（現時点ではそうではないことがわかっています）。

interface A1 {
    a: number;
    b: boolean;
}
interface A2 {
    [index: "a"]: number;
    [index: "b"]: boolean;
}

だから、私たちはただ書くことができます

declare function pluck<P, T extends { [indexer: P]: R; }, R>(obj: T, p: P): R;

考慮する必要があることがいくつかあります。

• Pが文字列リテラルのみになり得ることを示す方法は？
  
  
  
  • 文字列は技術的にすべての文字列リテラルを拡張するため、 P extends stringはあまりイデオマティックではありません
  
  
  • P super string制約の許可について他の議論が行われています（＃7265、＃6613、https：//github.com/Microsoft/TypeScript/issues/6613#issuecomment-175314703）
  
  
  • 私たちは本当にこれを気にする必要がありますか？ Tにstringまたはnumberのインデクサーがある場合、インデクサータイプに受け入れられるものなら何でも使用できます。 その場合、 Pはstringまたはnumberます。
  
  
• 現在、2番目の引数として"something"を渡すと、タイプはstring
  
  
  
  • 文字列リテラル＃10195が答えになる可能性があります
  
  
  • またはTSは、許容できる場合は、より具体的なPを使用する必要があると推測できます。
  
  
• インデクサーは暗黙的にオプションです{ [i: string]: number /* | undefined */ }
  
  
  
  • ドメインにundefinedを本当に入れたくない場合、どのように強制するのですか？
  
  
• P 、 T 、 R間のすべての関係の自動型推論は、それを機能させるための鍵です

@weswigham @mhegazy 、そして私は最近これについて話し合っています。 発生した開発についてお知らせします。これはアイデアのプロトタイプを作成しただけであることに注意してください。

現在のアイデア：

• 文字列リテラルタイプとしてFooからプロパティ名の和集合を取得するためのkeysof Foo演算子。
• Foo[K]タイプ。これは、一部のタイプのKが、文字列リテラルタイプまたは文字列リテラルタイプの和集合であることを指定します。

これらの基本ブロックから、適切なタイプとして文字列リテラルを推測する必要がある場合は、次のように記述できます。

function foo<T, K extends keysof T>(obj: T, key: K): T[K] {
    // ...
}

ここで、 Kはkeysof Tサブタイプになります。これは、文字列リテラル型または文字列リテラル型の和集合であることを意味します。 keyパラメータに渡すものはすべて、そのリテラル/リテラル​​の和集合によってコンテキストで型指定され、シングルトン文字列リテラル型として推測される必要があります。

例えば

interface HelloWorld { hello: any; world: any; }

function foo<K extends keysof HelloWorld>(key: K): K {
    return key;
}

// 'x' has type '"hello"'
let x = foo("hello");

最大の問題は、 keysofがしばしばその操作を「遅らせる」必要があるということです。 型を評価する方法に熱心すぎます。これは、私が投稿した最初の例のように型パラメーターの問題です（つまり、本当に解決したいのは、実際には難しい部分です：smile :)。

それがあなたにすべてのアップデートを与えることを願っています。

@DanielRosenwasser更新していただきありがとうございます。 @weswighamがkeysofオペレーターに関するPRを提出したのを見たばかりなので、この問題を皆さんに渡す方が良いかもしれません。

なぜあなたは最初に提案された構文から離れることを決めたのだろうか？

function get(prop: string): T[prop];

keysofを紹介しますか？

T[prop]はそれほど一般的ではなく、多くのインターレース機械を必要とします。 ここで一つの大きな問題は、あなたもの文字通りの内容関連したい方法ですpropのプロパティ名にT 。 私はあなたが何をするのか完全にはわかりません。 暗黙の型パラメーターを追加しますか？ コンテキストタイピングの動作を変更する必要がありますか？ 署名に何か特別なものを追加する必要がありますか？

答えはおそらくそれらすべてにイエスです。 私の腸は、2つのより単純で別々の概念を使用し、そこから構築する方がよいと私に言ったので、私はそれから私たちを追い出しました。 欠点は、特定の場合にボイラープレートが少し増えることです。

これらの種類のパターンを使用する新しいライブラリがあり、その定型文によってTypeScriptでの記述が困難になっている場合は、それを検討する必要があります。 しかし、全体として、この機能は主に図書館の消費者にサービスを提供することを目的としています。とにかく、使用サイトはここでメリットを得る場所だからです。

@DanielRosenwasserうさぎの穴をかろうじて降りた。 @SaschaNazのアイデアの実装にまだ問題はありませんか？ この場合、 keysofは冗長だと思います。 T[p] 、 pがTの文字通りの小道具の1つでなければならないことをすでに示しています。

私の大まかな実装の考えは、 PropertyReferencedTypeと呼ばれる新しいタイプを導入すること

export interface PropertyReferencedType extends Type {
        property: Symbol;
        targetType: ObjectType;
}

PropertyReferencedType戻り値の型で宣言された関数を入力するか、 PropertyReferencedTypeを参照する関数を入力する場合： ElementAccessExpression型は、を参照するプロパティで拡張されます。アクセスされたプロパティのシンボル。

export interface Type {
        flags: TypeFlags;                // Flags
        /* <strong i="20">@internal</strong> */ id: number;      // Unique ID
        //...
        referencedProperty: Symbol; // referenced property
}

したがって、参照されるプロパティシンボルを持つタイプは、 PropertyReferencedType割り当てることができます。 チェック中、 referencedProperty pはT[p] pに対応している必要があります。 また、要素アクセス式の親タイプは、 T割り当て可能である必要があります。 そして、物事を簡単にするために、 pもconstでなければなりません。

新しいタイプPropertyReferencedTypeは、「未解決のタイプ」として関数内にのみ存在します。 コールサイトでは、タイプをp解決する必要があります。

interface A { a: string }
declare function getProp(p: string): A[p]
getProp('a'); // string

PropertyReferencedTypeは関数の割り当てを介してのみ伝播し、呼び出し式を介して伝播することはできません。 PropertyReferencedTypeは、戻り値の型T[p]を持つ関数の本体のチェックを支援するための一時的な型にすぎないためです。

keysofとT[K]型の演算子を導入した場合、次のように使用できることを意味します。

interface A {
  a: number;
  b: string;
}
type AK = keysof A; // "a" | "b"
type AV = A[AK]; // number | string ?
type AA = A["a"]; // number ?
type AB = A["b"]; // string ?
type AC = A["c"]; // error?
type AN = A[number]; // error?

type X1 = keysof { [index: string]: number; }; // string ?
type X2 = keysof { [index: string]: number; [index: number]: string; }; // string | number ?

@DanielRosenwasserあなたの例は私の例と同じ意味ではないでしょう

function foo<T, K extends keysof T>(obj: T, key: K): T[K] {
    // ...
}
// same as ?
function foo<K, V, T extends { [k: K]: V; }>(obj: T, key: K): V {
    // ...
}

アンダースコアの_.pickの署名がどのように書き込まれるかわかりません：

o2 = _.pick(o1, 'p1', 'p2');

pick(Object, ...props: String[]) : WHAT GOES HERE;

@rtmhttps ： //github.com/Microsoft/TypeScript/issues/1295#issuecomment-234724380で提案しました。 これに関連していても、新しい号を開く方が良いかもしれませんが。

実装は＃11929で利用可能になりました。