インテリセンスなどを使用してVSCodeでこれをすばやくプレイする方法が必要な場合は、ここにプレイグラウンドリポジトリがあります。

タイプP=typeof foo（0）; //Pはany[]
タイプQ=typeof foo（true）; //Qは文字列です

値の代わりに型を引数として使用する方がより有効な構文だと思います。

type P = typeof foo(number);    // P is any[]
type Q = typeof foo(boolean); // Q is string

引数として値ではなく型を指定するため、関数が呼び出されていないことがより明確になります。 もう1つのポイントは、あいまいさが少ないことです。 typeof foo(false)を使用する人もいれば、 typeof foo(true)を使用する人もいます。 引数として型がある場合、人々はtypeof foo(boolean)しか書くことができません。

@tinganhoまさに！
＃5185でtypeof foo("abc")を書くことはできますが
ここで"abc"はシングルトン文字列型です

@tinganho私はあなたのアイデアにいくつかの考えを与えてきました、そして私はこの提案について私が好むいくつかのこと、そしてあなたの提案について私が好む他のことを見ます。 あなたの提案はあなたが与えた理由のために良いです（より単純でより明確な構文、より曖昧さが少なく、関数呼び出しのように見えません）。 私の提案で私が好むのは、新しい構文が導入されていないため、パーサー/チェッカーに複雑さが加わらないことです。また、引数に単純な型名がない、より複雑なシナリオもサポートします。

foo(number)構文のようなものを、既存の式解析メカニズムを使用して書く非常に簡単な方法があるとしたらどうでしょうか。 そこで、実験として、新しい式_unaryas_を導入しました。 as Tと書くだけで、 (null as T)の省略形になります。 あなたは基本的に、_'値は気にしませんが、式にタイプX'_を持たせたいと言っています。

この変更（私はプレイグラウンドリポジトリに実装しました）を使用すると、提案された構文に非常に近いものを記述できますが、それでも通常の式として解析されます。

type P = typeof foo(as number);    // P is any[]
type Q = typeof foo(as boolean); // Q is string

let prop2: typeof (as MyInterface).prop1.big.complex; // prop2 type is {anonymous: {type: {}}}

これは簡単な実験でした。 同等の構文は次のようになります（ただし、これは実装していません）。

type P = typeof foo(<number>);    // P is any[]
type Q = typeof foo(<boolean>); // Q is string

let prop2: typeof (<MyInterface>).prop1.big.complex; // prop2 type is {anonymous: {type: {}}}

2番目の構文は_nullaryタイプのアサーション_と呼ばれる場合があり、式<T>は(<T> null)の省略形です。

@yortus 、先週、この提案について話し合った。 以前に投稿しなかったことをお詫びします。 コンセンサスは1でした。たとえば、関数の戻りやクラス式のインスタンスタイプなど、一部のタイプを参照できないという問題があります。 2.型の位置に式を追加することは、私たちが慣れていることではありません。

@tinganhoの提案も私たちが話し合ったものでした。 実装はおそらくもっと複雑になるでしょうが、私はそれがより口当たりが良いと思います。 新しい単項演算子を追加したり、キャスト構文を使用したりすることは、型名を使用するだけの場合ほど洗練されていません。

今日のスローガンでかなり長い間議論されました。 ここでの「PRの受け入れ」は、「実装があまりにもクレイジーであることが判明しないと仮定してPRを受け入れる」です。

@tinganhoの提案は（少なくとも他のオプションと比較して）かなり良さそうです。これを実装する暫定的なPRが必要です。

トリッキーなことは、 f(number)とf(0)の戻り型を解決するために完全に別個のコードパスを持たせたくないということですが、過負荷解決アルゴリズムは完全に組み込まれています。 _types_のセットではなく、_expressions_のセットで動作します。 しかし、少し注意を払えば、これは簡単なはずです。

攻撃の基本的な計画は次のとおりです。

• typeofを解析するときに文法を拡張して、関数呼び出し、プロパティアクセス、インデックス付きプロパティアクセスのように見えるものを許可します
• 型クエリで関数呼び出しの引数を解析する場合（それらを_psuedocalls_ / _psuedoarguments_と呼びましょう）、 parseType関数を使用します。 これによりTypeNodeが作成されますが、型クエリのコンテキストで解析された型であることを示すフラグをノードに設定します
• チェッカーでは、 checkExpressionがこのフラグをチェックし、通常の式処理の代わりにgetTypeFromTypeNodeを呼び出します。

@ mhegazy 、 @ RyanCavanaughは、チームが話し合ったコーナーケースの数がわからないので、説明のためにここにいくつか挙げることができますか？ 以下に多数の例をリストし、それぞれにtypeof操作の結果であると思われるものと、疑わしいケースに疑問符を付けてコメントしました。

インデクサー表記

var data = [1, 2, 3];
const LOBOUND = 0;
type Elem1 = typeof data[0];        // number
type Elem2 = typeof data[999999];   // number or ERROR?
type Elem3 = typeof data[1+2];      // ERROR or number?
type Elem4 = typeof data[LOBOUND];  // ERROR or number?

var tuple: [number, string] = [123, 'abc'];
type Elem4 = typeof tuple[0];       // number or number|string?
type Elem5 = typeof tuple[1];       // string or number|string?
type Elem6 = typeof tuple[999999];  // number|string or ERROR?

const ABC: 'a-b-c' = 'a-b-c';
let dict = { 'a-b-c': 123, 'd-e-f': true };
type Prop1 = typeof dict['a-b-c'];  // number
type Prop2 = typeof dict['d-e-f'];  // boolean
type Prop3 = typeof dict[ABC];      // ERROR or number or any?

関数戻り型表記

// A simple function
declare function f1(n: number): string[];
type Ret1 = typeof f1(number);      // string[]
type Ret2 = typeof f1(0);           // ERROR or string[]?

// An asynchronous function that either accepts a callback or returns a Promise
declare function f2(n: number): Promise<string[]>;
declare function f2(n: number, cb: (err?: any, result?: string[]) => void): void;
type Ret3 = typeof f2(number);                    // Promise<string[]>
type Ret4 = typeof f2(number, any);               // void
type Ret5 = typeof f2(number, Function);          // ERROR: Function not assignable to callback
type Ret6 = typeof f2(number, (err: any, result: string[]) => void); // void
type Ret7 = typeof f2(number, (...args) => any);  // void

// A special function-like object
interface Receiver {
    (data: string[]): void;
    transmogrify(): number[];
}
declare function f3(n: number, receiver: Receiver): Promise<void>;
declare function f3(n: number, callback: (err?: any, result?: string[]) => void): void;
type Ret8 = typeof f3(number, Receiver);           // Promise<void>
type Ret9 = typeof f3(number, any);                // ambiguous? or picks first overload?
type Ret10 = typeof f3(number, Function);          // ERROR
type Ret11 = typeof f3(number, (...args) => any);  // void since not assignable to Receiver

// A function with parameter destructuring
interface CartesianCoordinate {/***/}
interface PolarCoordinate {/***/}
declare function f4({ x: number, y: number }): CartesianCoordinate;
declare function f4({ r: number, t: number }): PolarCoordinate;
type Ret12 = typeof f4(any);        // ambiguous? or picks first overload?
type Ret13 = typeof f4({x;y});      // CartesianCoordinate
type Ret14 = typeof f4({r;t});      // PolarCoordinate
type Ret15 = typeof f4({x;r;t;y});  // ambiguous? or picks first overload?

// Type-ception: is there anything wrong with typeof-in-typeof?
declare function f5(n: number, receiver: Receiver): Promise<void>;
declare function f5(n: number, callback: (err?: any, result?: string[]) => void): void;
function myCallback(err, result) {/***/}
var myReceiver: Receiver;
type Ret16 = typeof f5(number, typeof myReceiver); // Promise<void>
type Ret17 = typeof f5(number, typeof myCallback); // void

クラス/インターフェースタイプの一部を抽出する

つまり、上記のtypeof (<MyInterface> null).prop1.big.complex;の例です。

上記のコメントから、これは範囲外であり、サポートされないことがわかります。 あれは正しいですか？

インデクサー表記

var data = [1, 2, 3];
const LOBOUND = 0;
type Elem1 = typeof data[0];        // number
type Elem2 = typeof data[999999];   // number
type Elem3 = typeof data[1+2];      // ERROR, only literals allowed here
type Elem4 = typeof data[LOBOUND];  // number when const resolution is done, otherwise any

var tuple: [number, string] = [123, 'abc'];
type Elem4 = typeof tuple[0];       // number
type Elem5 = typeof tuple[1];       // string 
type Elem6 = typeof tuple[999999];  // number|string

const ABC: 'a-b-c' = 'a-b-c';
let dict = { 'a-b-c': 123, 'd-e-f': true };
type Prop1 = typeof dict['a-b-c'];  // number
type Prop2 = typeof dict['d-e-f'];  // boolean
type Prop3 = typeof dict[ABC];      // number when const resolution work is done, otherwise any

関数戻り型表記

// A simple function
declare function f1(n: number): string[];
type Ret1 = typeof f1(number);      // string[]
type Ret2 = typeof f1(0);           // error, 0 is not a type

// An asynchronous function that either accepts a callback or returns a Promise
declare function f2(n: number): Promise<string[]>;
declare function f2(n: number, cb: (err?: any, result?: string[]) => void): void;
type Ret3 = typeof f2(number);                    // Promise<string[]>
type Ret4 = typeof f2(number, any);               // void
type Ret5 = typeof f2(number, Function);          // ERROR: Function not assignable to callback
type Ret6 = typeof f2(number, (err: any, result: string[]) => void); // void
type Ret7 = typeof f2(number, (...args) => any);  // void

// A special function-like object
interface Receiver {
    (data: string[]): void;
    transmogrify(): number[];
}
declare function f3(n: number, receiver: Receiver): Promise<void>;
declare function f3(n: number, callback: (err?: any, result?: string[]) => void): void;
type Ret8 = typeof f3(number, Receiver);           // Promise<void>
type Ret9 = typeof f3(number, any);                // picks first overload
type Ret10 = typeof f3(number, Function);          // ERROR
type Ret11 = typeof f3(number, (...args) => any);  // void since not assignable to Receiver

// A function with parameter destructuring
interface CartesianCoordinate {/***/}
interface PolarCoordinate {/***/}
declare function f4({ x: number, y: number }): CartesianCoordinate;
declare function f4({ r: number, t: number }): PolarCoordinate;
type Ret12 = typeof f4(any);        // picks first overload
type Ret13 = typeof f4({x;y});      // CartesianCoordinate
type Ret14 = typeof f4({r;t});      // PolarCoordinate
type Ret15 = typeof f4({x;r;t;y});  // picks first overload

// Type-ception: is there anything wrong with typeof-in-typeof?
declare function f5(n: number, receiver: Receiver): Promise<void>;
declare function f5(n: number, callback: (err?: any, result?: string[]) => void): void;
function myCallback(err, result) {/***/}
var myReceiver: Receiver;
type Ret16 = typeof f5(number, typeof myReceiver); // Promise<void>
type Ret17 = typeof f5(number, typeof myCallback); // void

ここで何が起こるのか興味があります：

const number = "number";
type Ret3 = typeof f2(number); // What happens here?

@SaschaNaz良い質問です。 同様の状況：

class MyClass { foo; bar; }
declare function f(inst: MyClass): number;
type Ret = typeof f(MyClass);     // number (presumably)

この場合、 typeof f(MyClass)でMyClass _type_をMyClass _value_（つまりコンストラクター関数）の前に考慮することは理にかなっています。 前者はRet = numberにつながり、後者はerror: MyClass is not a typeのようなものになります。

_type_と_constvalue_の両方を参照する名前にも同じロジックが適用されますか？ あなたの例では、タイプnumberが常にconst値numberよりも優先されることを意味します。 @RyanCavanaughについて何か考えはありますか？

そうです、これは型式の通常のセマンティクスの下で解決されます（ var x: [whatever]を記述したかのように）。 したがって、 typeof f(MyClass)はインスタンス側でのfの呼び出しを参照し、 typeof f(typeof MyClass)はコンストラクター関数でのfの呼び出しを参照することができます。

では、 @ SaschaNazの例では、 numberを_const value_ではなく、_type_として明確に参照していますね。

const number = "number";
type Ret3 = typeof f2(number); // Promise<string[]>

@RyanCavanaughは、ユースケースの3番目のグループが範囲外であることを確認できますか？ 例：OPから：

// Declare an interface DRY-ly and without introducing extra type names
interface MyInterface {
    prop1: {
        big: {
            complex: {
                anonymous: { type: {} }
            }
        }
    },

    // prop2 shares some structure with prop1
    prop2: typeof (<MyInterface>null).prop1.big.complex; // OK: prop2 type is {anonymous: {type: {}}}
}

このユースケース（構文は問わない）は、現時点ではサポートされていませんね。

this式を許可することで、これをカバーする必要があります。

   prop2: typeof this.prop1.big.complex;

constは、別のtypeofで解決する必要があると思います。

type Ret3 = typeof f2(typeof number); // typeof number is string so error here

...これはtypeof data[LOBOUND]をブロックしますが。

@mhegazyそれはtypeof thisに関して素晴らしいアイデアです。 私は、これがこの提案のために作成したフォークされた実装ですでに機能していることに気づきました。 まあ、それはクラスのために働きます。 インターフェイスの場合、エラーは発生しませんが、 thisタイプは常にanyとして推測されます。 フォークされたimplからの現在の出力：

class MyClass {
    prop1: {
        big: {
            complex: {
                anonymous: { type: {} }
            }
        }
    };

    prop2: typeof this.prop1.big.complex; // prop2 type is {anonymous: {type: {}}}
}

interface MyInterface {
    prop1: {
        big: {
            complex: {
                anonymous: { type: {} }
            }
        }
    };

    prop2: typeof this.prop1.big.complex; // prop2 type is any
}

インターフェイス宣言内thisを推測する可能性はありますか、それともこの機能はクラスに限定されたままですか？

＃6179とAngularについて2つのポイントを述べたいと思います。

// A factory function that returns an instance of a local class
function myAPIFactory($http: HttpSvc, id: number) {
    class MyAPI {
        constructor(token: string) {...}
        foo() {...}
        bar() {...}
        static id = id;
    }
    return MyAPI;
}
type MyAPIConstructor = typeof myAPIFactory(null, 0); // OK: MyAPI is myAPIFactory's return type
function augmentAPI(api: MyAPIConstructor) {...} // OK

1. パラメータの数は多くなる可能性があります。 15個のパラメータを考えてみましょう。 同時に、オーバーロードはなく、 typeofのパラメーターが必要なのはオーバーロードだけです。 したがって、この場合、おそらく次のような構文を考えることができますか？

   type MyAPI = typeof myAPIFactory(...);
   

2. 通常、ファクトリ関数は独自のグローバル変数に割り当てられません。 関数式が使用されます：

   angular.module('app').factory('MyAPI', function($http: HttpSvc, id: number) { /*...*/ });
   

   それは通常それがどのように見えるかです。 ご覧のとおり、ここではtypeofはまったく使用できません。

@ thron0私の直感では、パラメータがいくつかあるが、匿名型を返すものは非常にまれです。 どう思いますか？

Angular 1がレアになると、それ以前ではなく、レアになります。

基本的に、あなたが説明したのは、典型的なAngular_factory_です。

いくつかのパラメータを持っているが、匿名タイプも返すもの

これは、依存関係をパラメーターとして受け取り、_service_のインスタンスを作成する関数です。 多数のパラメーターが面倒になる可能性があると考えるかもしれませんが、問題は、それらのファクトリが直接呼び出されることはないということです。 DIコンテナはそれらを呼び出します。 ファクトリは、依存関係として戻り値（サービス）が必要な場合に呼び出されます。 また、Angularではサービスは常にシングルトンであるため、一度だけ呼び出されます。 ただし、サービスは何でもかまいません。したがって、シングルトン以外の動作が必要な場合、ファクトリはコンストラクター（またはファクトリ関数）を返すことができます。 このコード例のように：

angular.module('app').factory('MyAPI', function($http: HttpSvc, id: number) {
    class MyAPI {
        constructor(token: string) {...}
        foo() {...}
        bar() {...}
        static id = id;
    }
    return MyAPI;
});

この状況に対する私の現在の回避策は次のようになります。

class MyAPI {
    // dependencies (1)
    protected $http: HttpSvc;
    protected id: number;

    constructor(token: string) {...}
    foo() {...}
    bar() {...}
    // Static properties cannot be used with this approach because:
    // 1) this class is a global variable so it can be shared by different 
    // instances of the DI container,
    // 2) the id property isn't available here as it's initialized in the subclass
    //// static id0 = id;
}

angular.module('app').factory('MyAPI', function($http: HttpSvc, id: number) { // (2)
    return class extends MyAPI {
        $http = $http; // (3)
        id = id;
    };
});

// this type is needed for type annotations in the services that require MyAPI as a dependency
type MyAPIConstructor = typeof MyAPI;

angular.module('app').factory('someOtherService', function(MyAPI: MyAPIConstructor) {
    var api = new MyAPI('qwerty');
    /* ... */
});

ご覧のとおり、それは完全に醜くて苦痛です。 依存関係を3回リストする必要があります。 より多くの依存関係がある場合は、通常の方法（ファクトリ関数内）でクラスを記述し、そのコンシューマーのインターフェースを宣言する方が簡単な場合があります。

こんにちは、構文/セマンティクスのタイプをそのままにして、代わりに単純なタイプアクセス代数を実装することを提案したいと思います。

タイプ構文の拡張を想像してみましょう。

type          ::=  ... |  literalType | type typeAccess | guarded
guarded    ::= "type" id
literalType   ::= stringLiteral | numberLiteral | symLiteral | booleanLiteral 
typeAccess    ::= typeField | typeSubscript | typeCall
typeField     ::= "." id
typeSubscript ::= "[" type "]"
typeCall      ::= "(" [type {"," type}] ")"

スコープ内の各識別子は、2つのエンティティに同時にバインドできます。

• コンパイル時のタイプ
• 実行時の値

タイプガードは前者のみを抽出します。 したがって

class A {}
var a: A;

と同等です

class A {}
var a: type A;

この場合、クラスがあれば

class ABC {
    a: number;
    b(x: number): string;
    c:string[];
    d:[number, string];
}

その後、私たちは書くことができます

var a: (type ABC).a; // number
var b: (type ABC).b(number); // string
var c: (type ABC).c[number]; // string
var d: (type ABC).c[0]; // number

また、字句スコープ内の同じ識別子の下にある_type_エンティティと_value_エンティティのマージについても説明します。

interface SAME {
    x: number;
}
namespace SAME: {
    export type x = boolean;
    export var x: string;
}

var a: SAME.x   // boolean
var b: (type SAME).x  // number
var b: (typeof SAME).x  // string

@ RyanCavanaugh 、 @ sandersnこのアイデアを検討できますか？

提案で表現のタイプをどのように捉えますか？

2016年5月19日木曜日12:26AnatolyRessin、 notifications @github.comは次のように書いています。

こんにちは、構文/セマンティクスのタイプをそのままにして、
代わりに、単純なタイプのアクセス代数を実装します。

タイプ構文の拡張を想像してみましょう。

タイプ::=... | literalType | タイプtypeAccess| 守られた
保護された::="type" id
literalType :: = stringLiteral | numberLiteral | symLiteral | booleanLiteral
typeAccess :: = typeField | typeSubscript | typeCall
typeField ::="。" id
typeSubscript :: = "[" type "]"
typeCall :: = "（" [type {"、" type}] "）"

スコープ内の各識別子は、2つに同時にバインドできます
エンティティ：

• コンパイル時のタイプ
• 実行時の値

_type_ガードは前者のみを抽出します。 したがって

クラスA{}
a：A

と同等です

クラスA{}
a：タイプA

この場合、クラスがあれば

クラスABC{
数;
b（x：数値）：文字列;
c：string [];
d：[数値、文字列];
}

その後、私たちは書くことができます

var a :(タイプABC）.a; // numbervar b：（type ABC）.b（number）; // stringvar c：（type ABC）.c [number]; // stringvar d :(タイプABC）.c [0]; // 番号

また、_type_エンティティと_value_エンティティを
字句スコープ内の同じ識別子。

インターフェイスSAME{
x：数;
}名前空間同じ：{
エクスポートタイプx=ブール値;
エクスポート変数x：文字列;
}
var a：SAME.x // booleanvar b：（type SAME）.x // numbervar b：（typeof SAME）.x//文字列

@RyanCavanaugh https://github.com/RyanCavanaugh、@ sandersn
https://github.com/sandersnこのアイデアを検討できますか？

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/6606#issuecomment -220378019

あなたの例は、点線の式のタイプとタイププロパティタイプ＃1295が非常に似た提案であることを思い出させます。 一方がより静的で、もう一方がより動的であることを除いて。

typeofキーワードをスキップするというアイデアも好きです。

   prop2: this.prop1.big.complex;

あなたの例では@mhegazyがthis-expressionでtypeofを使用しています：

prop2: typeof this.prop1.big.complex;

今日これを行うことができるので：

someProp: this;

私の見解では、点線のプロパティを増やすための上記の構文の外挿は次のとおりです。

someProp: this.prop1.prop2.prop3;

そしてそうではありません：

someProp: typeof this.prop1.prop2.prop3;

そして、外挿を続けるために— typeofをすべて一緒にスキップしてみませんか？

someProps: foo(number)

typeofを一緒にスキップしてみませんか？

私が考えることができる理由の1つは、クラスのインスタンス側を参照しているのか、静的側を参照しているのかがあいまいになることです。

class C {}

// Does 'x' have the instance type of 'C',
// or does it have the shape of its constructor?
let x: C;

別のインターフェース内のインターフェースのプロパティのタイプも参照したいと思います。 私の例を＃10588として投稿しましたが、このチケットのために現在は閉鎖されています。

そのようなものを書くといいでしょう：

interface Foo {
  bar: string;
}

interface Box<T> {
  container: T;
}

interface FooWithBoxedProps {
  bar: Box<Foo.bar>; // OR: bar: Box<typeof Foo.bar>;
}

これは単にこれに変換されます：

interface Foo {
  bar: string;
}

interface Box<T> {
  container: T;
}

interface FooWithBoxedProps {
  bar: Box<string>;
}

前述のシナリオのいくつかは、_インデックス付きアクセスタイプ_（＃11929）で表現できるようになりました。 この機能を標準のtypeof式と組み合わせるだけで、次のようになります。

interface MyInterface {
    prop1: {
        big: {
            complex: {
                anonymous: { type: {} }
            }
        }
    },

    // prop2 shares some structure with prop1
    prop2: MyInterface["prop1"]["big"]["complex"];
}

そしてそれは動作します！ （現在typescript @ nextにあります）

次の自然なことは似たようなものになると思いますが、関数の場合、次のようないくつかの「関数呼び出しタイプ」があります。

interface FunctionLike{
    (arg1 : number, arg2 : string) : {a : number; b : string;}
}

type ReturnType = FunctionLike(number, string); // {a : number; b : string;} 

したがって、 typeof演算子と自然に組み合わせることができます

interface BigThing {
    testString: string;
    testNumber: number;
    testBoolean: boolean;
}

function getSmallThing(thing:BigThing){
    return {
        testString : thing.testString,
        testBoolean : thing.testBoolean
    }
}

type SmallThing = typeof getSmallThing(BigThing) // {testString: string; testBoolean : boolean}

そして、これはこのスレッド（@tinganho）の冒頭ですでに提案されている構文のようです。 :)
ただし、現在の_インデックス付きアクセスタイプ_と同様に、現在のtypeof演算子を使用して適切に構成する方がより一般的な機能になります。

ただし、いくつかの質問/疑問が残っています。

• この機能は、_インデックス付きアクセスタイプ_のような他のシナリオを処理しますか？ そうでない場合は、それを実装する価値がありますか？
• ほとんどの場合、引数の型をまったく指定する必要がないのがいいと思います。最も一般的なシナリオは、「他のオーバーロードがないこの1つの関数の型を取得したいだけです」からです。このための新しい特定の演算子で問題ありません（たとえば、 typeofreturnまたはreturnof ）

これは技術的に実現可能のようです。 引数を解決する必要がないように、オーバーロード解決/型引数推論のリファクタリングが必要になる場合があります。 ジェネリックスが追加の問題をあまり引き起こさないと思います。 質問の1つは、呼び出しに一致するオーバーロードがない場合にどうなるかです。

この機能が望ましいかどうかは明らかではないと思います。 関数が非常に複雑な匿名型を返す場合、このように参照する必要がないように、型に名前を付けることは作成者としてより役立つのではないでしょうか。 私はこれが単に文体の好みに基づいていることを認めます。 これが実際にどれほど便利かわからないと思います。 ただし、要素アクセスには問題ないと思います。

タイプP=typeof foo（0）; //Pはany[]
タイプQ=typeof foo（true）; //Qは文字列です

パラメータをそのタイプで参照できるようにすることについてのこの議論では、実際の関数にも同じことを許可することをお勧めします。
コンテキスト：オブジェクトに対してmapに関数を入力したい：
function map<T, F extends Function>(fn: F, obj: T): { [P in keyof T]: typeof F(T[P]) }
関数をそのタイプF （名前fnだけでなく）で参照できるようにしたい理由は、その名前が使用できない可能性がある場合です。 d type MapFn<T, F extends Function> = { [P in keyof T]: typeof F(T[P]) }と言えるようにしたい。

おそらく実装がはるかに簡単である（そしてそれでも非常に役立つ）ものは次のようになります。

const myFunc = () => ({ x: 10 });
type myType = returnof myFunc;    // { x: number; }

理論的には、タイプを数レベル深くしたい場合は、それらを連鎖させることもできます。 何かご意見は？

編集：これが@mpawelskiによって上で言及されたことに気づきました😄

@dehliただし、オーバーロードされた関数では機能しません。 または、戻り型で型パラメーターが使用されるジェネリック関数。

@JsonFreemanさまざまなリターンタイプだけで関数をオーバーロードできませんORたか？ そして総称関数はあなたがタイプを指定することを要求するかもしれませんか？

それは可能ですが、それがどれほど役立つかはわかりません。 人々はもっと洗練されたものを望んでいるようです。

本当に苦痛なので、これがすぐに実装されることを本当に望んでいます。

回避策

最後の回避策はもう機能しないので、私は現在これを使用しています：

// 0 argument function
export default function returnof<T>(fn: () => T): T;

// 1 argument function
// If no ambiguity simply infer the return type
export default function returnof<A, T>(fn: (a: A) => T): T;

// 1 argument function, with possible overload for the argument type.
// Explicitly set the type and use the correct overload
export default function returnof<A, T>(fn: (a: A) => T, a: A): T;

// ...

関数のオーバーロードがない場合は、引数を指定する必要はありません。

const hello = (arg: number) => 'World'

const helloReturnValue = returnof(hello)
type helloReturnType = typeof helloReturnValue // string

オーバーロードされた関数

declare function hello(): void;
declare function hello(a: number): number;

const helloReturnValue = returnof(hello)
type helloReturnType = typeof helloReturnValue // void

const helloReturnValue = returnof(hello, 42)
type helloReturnType = typeof helloReturnValue // number

すべての定義はここにあります：
https://github.com/kube/returnof/blob/master/lib/returnof.d.ts

プロジェクトを汚染することなく簡単にバンドルできるように、小さなNPMパッケージを作成しました。

https://github.com/Microsoft/TypeScript/issues/2175で提案されているようにオプションのジェネリックスが追加された場合、単純な宣言型のみの回避策が可能になります。

type Return<T extends () => S, S> = S

そして、次のように使用します。

type helloReturnType = Return<typeof hello>

@mhegazy @JsonFreemanこの機能に関する計画はありますか？

皆さんこんにちは、
私はこの問題に対する代替の可能な解決策を持っています（それがすでに提案されていて、私がそれを逃した場合は申し訳ありません）-私は問題＃13949でそれを提案しました。 その段階では演算子の種類については知りませんでしたが、私の解決策はもっと一般的だと思います。 基本的に、 =MyTypeのような新しい構文を導入します。これは、 MyTypeを使用する場所ならどこでも使用できますが、オブジェクトがMyType型であると宣言する代わりに、オブジェクトの推測された型からMyTypeという名前の型。 たとえば、これはVueコンポーネントの作成に使用する方法です。

function createData(){
  return <=MyData>{
    dataProp1: <string>null
  }
}

function method1(){
  let self: MyComponent = this;
  console.log(self.dataProp1);
  self.method2();
}

function method2(){
  let self: MyComponent = this;
  //dostuff
}

type MyComponent = MyData & MyMethods;

let componentOptions = {
  data: createData,
  methods: <=MyMethods>{method1, method2}
}
//todo: register component...

createData関数は次のように書くこともできます。

function createData(): =MyData {
  return {
    dataProp1: <string>null
  }
}

私は、あらゆる表現に一般化する本当に楽しい回避策を見つけました：

const varWithRightType = (false as true) && some.deep.access()
type MyType = typeof varWithRightType;

編集：私に笑うのをやめなさいこれは深刻なタイプスクリプトです

@johnfnこれは単純なケースでは面白そうです:)が、関数にいくつかのパラメータが必要な場合は、次のように追加の回避策を講じる必要があります。

const stateProps = (false as true) && mapStateToProps({} as any);

私は別の回避策を使用しています。これは、型推論を使用してmapStateToProps関数から小道具の型を取得しようとするときにReactとReduxで特に役立ちます。 そうすれば、Redux connectによって注入されたプロップのインターフェースを手動で宣言して維持する必要がなくなります。これは維持が面倒でエラーが発生しやすくなります。
この回避策は、他のユースケースの特定の関数シグネチャも適切に処理します。

typeof演算子「React＆Redux」のユースケースの例：

以下の例では、 typeof演算子を使用して、TypeScriptに追加すると非常に役立つ関数宣言から型を導出するための、一般的な実際のプロジェクトのユースケースを示します。

import { returntypeof } from 'react-redux-typescript';
import { RootState } from '../../store';
...

const mapStateToProps = (state: RootState) => ({
  currencies: CurrencyRatesSelectors.getCurrencies(state),
  currencyConverter: storeState.currencyConverter,
});

const stateProps = returntypeof(mapStateToProps); 
type Props = typeof stateProps & typeof dispatchToProps;
type State = {};

class CurrencyConverterContainer extends React.Component<Props, State> {
...

ソース： https ：//github.com/piotrwitek/react-redux-typescript-patterns#react -connected-components

@kubeのソリューションとそのパッケージhttps://github.com/kube/returnofは期待どおりに機能しているようです！ 👍

うーん。 returnofが.d.tsファイルからタプルベースのmap()を入力するのに役立つことを望みますが、式言語に依存しているため（ constはアンビエントコンテキストでは使用できません） ）、私はそれを使った私のユースケースが少なくとももっと複雑になるのではないかと心配しています。

編集：オプションのジェネリックが今ではマージされているようです。つまり、 @ kubeの宣言型言語のみのバージョン（ type Return<T extends () => S, S> = S -> type helloReturnType = Return<typeof hello> ）が実行可能になります。 ：D

訂正：いいえ、デフォルトのジェネリック値のマージされたサポートでは、ジェネリックの一部を指定することはできませんが、他の人は推測された値にフォールバックできます。 Return<typeof hello>はエラーGeneric type 'Return' requires 2 type argument(s).を生成します。

@tycho01うんそれが問題を解決しなかったことにがっかりした。

オプションのジェネリック型推論に関する関連する問題をすでに開いています：

14400

通常、ダミーのアンビエント関数と型推論を組み合わせて、関数の戻り型を取得できます。

アンビエントfunction returnTypeOf<RT>(fn:(...rest:any[])=>RT):RT {return void 0};
ローカルでvar r = returnTypeOf(someFunction);は値undefined $を取得します

しかし、そのリターンタイプを再利用したい場合は、それをキャプチャする必要があります...これで、最初の場所に戻ります。

type RT = typeof r;

最初にtypeofの概念を拡張して、 returntypeof $を許可するか、 typeof fn(a,b,c,...)からこの使用法を推測して、さまざまな署名の戻りタイプをキャプチャできるようにすると、はるかに簡単になります。 。 このリターンタイプの理解は、TSによってすでに内部的に実行されています。

typeofexpression ()は、タイプ操作と混合された一種のリターンタイプ再帰になります。

type E = typeofexpression (f(1) + g("x"))

は

type E = typecomprehensionof (typeof f(1) + typeof g("x"))

のように理解されるかもしれません

type E = typecomprehensionof (string + string)すなわちstring
type E = typecomprehensionof (string + number)すなわちstring
type E = typecomprehensionof (number + number)すなわちnumber

これが内部的にどれほど難しいか、そしてパフォーマンスコストは私にはわかりません。

編集 - - - - - - - - - - - - - - - - - - - - - - - - - ------------

追加するつもりでした...これは、Function.bind、Function.apply、Function.callを使用する必要がある人にとって特に重要です。これらは現在タイプanyを返し、これは常にタイプ-である必要があることを意味します。タイプチェックプロセスから外れないように注釈が付けられています。

関数の引数の戻り型を参照できるようになると、...至福...

@poseidonCore

関数の引数の戻り型を参照できるようになると、...至福...

私は現在のtypeof <expression>の方が好きで、リターンタイプの問題はすでに＃12342でカバーされています。

説明でこれらの使用法を区別する手段として、 typeofexpressionとtypecomprehensionofを使用していました。 実際の構文としてtypeof (expression)をお勧めします。

私のポイントは、式の型を理解するには、関数の戻り型を理解する必要があるということでした... f(1)も式です。 ＃12342はこのように関連しています。 それらは相互に排他的ではありません。

変数に対してはすでにtypeofを実行できます。式は変数と関数に対する演算であるため、次の要件は関数の型を返すことができることです...そして型の規則に基づいて結果を理解することです。

実は良い点です。 ＃12342が望んでいる問題は、ジェネリック型のプロパティのようなものとして戻り型にアクセスする方法であるため、関係を誤解しました。

提案のようにtypeof関数の呼び出しに式を使用しますが、パラメーターの代わりに型を直接使用するのはどうですか？

例えば

function myFunction<T>(param1: T, param2: string, param3: number): T & {test: string} {
  // ...
}

type ResultType = typeof myFunction({hello: string}, string, number)
// ResultType is: {hello: string} & {test: string}

これは、呼び出し内でtypeofを使用することにより、ローカルスコープの変数のタイプを使用することを妨げるものではないことに注意してください。

type ResultType = typeof myFunction(typeof obj, string, number)
// ResultType is: typeof obj & {test: string} 

これは、元の提案よりも少し優れているように見えます。これは、周囲の状況で機能し、一般的に柔軟性が高いように見えるためです。 また、実際には関数を呼び出しておらず、戻り値の型を返そうとしているだけであることも明確になります。

私の単純なケースでそれをどのように行ったか：

interface IAlertMessage {
  addedAt: number;
  text: string;
  type: "error" | "warning" | "info" | "success";
}

declare let alertMessageInterface: IAlertMessage;

const messages: IAlertMessage[] = [];

function addMessage(text: string, type: typeof alertMessageInterface.type): void {
  messages.push({addedAt: new Date().getTime(), text, type});
}

addMessage("something", "info"); // <- OK - and also has intellisense for the second parameter (after typing first " of the second parameter, press Ctrl+Space in VSCode)
addMessage("something", "fatal"); // <- Compilation error : error TS2345: Argument of type '"fatal"' is not assignable to parameter of type '"error" | "warning" | "info" | "success"'.

上記は、インターフェース自体のメンバーでも機能します。

declare let myIface: MyInterface;

interface MyInterface {
    prop1: {
        big: {
            complex: {
                anonymous: { type: {} }
            }
        }
    },
    prop2: typeof myIface.prop1.big.complex.anonymous;
}

type ... declare let ...を使用する利点は、出力.jsファイルに何も生成されないことです。

@varaderoこれは、関数呼び出しの戻り型を取得するという当面の問題を解決しません。 あなたがしているのは、TypeScript 2.2以降でサポートされている機能である、型のプロパティの型を取得することだけだと思います。

これは実際には（偽の）値のプロパティのタイプです。 コンパイラでは、typeofを「純粋な」型またはインターフェイスで使用することはできません。値に対してのみ機能します。

これは素晴らしいことです！

type KEYOF<T extends any[]> = keyof T[0]すでに存在するため、 function myFunc<T, K extends KEYOF<T>>(type: K)>{ }とmyFunc([(r: string) => r]) （ typeof T[0]('something')の文字列を返す）を想定すると、 typeof T[0]('something')もこの実装で機能します。 ？

これは、多形のthisと一緒に強力になります。

これが起こる時間です！

このスレッドを読み直して、 typeofで何をしているのか、そしてその理由を理解しようとしました。

明らかに、すでに実装されている些細なtypeof fooの場合、 fooのタイプになります。 （ pet is Fishは、特別な構文を使用しても影響を受けないと思います。）

このキーワードが現在の提案で何をすべきかについての私の現在の読書では、キーワード自体は現在のこと以上のことはせず、現在の提案は実際にはtypeofキーワードとは無関係です。

これは、前述の場合、値としてではなく、型（ typeまたはジェネリック）として格納された関数を適用する場合に重要であるためです。

それを考えると、 typeof fn<A>(string)は型レベルで使用するために式レベルの変数fn typeof $が必要ですが、一方でFn<A>(string)は、関数を含むジェネリックとしてFnを使用すると、それを必要としないため、 typeofを必要とせずに、ここで適切な戻り型を取得するために「適用」できます。

この解釈では、潜在的な関数型の後に関数呼び出しをチェックします。 typeof fn(...) / typeof fn<...>(...)のほかに、 Fn(...) / Fn<...>(...)も、関数でさえない場合はリテラル((foo: Foo) => Bar)(Baz) /+ジェネリック。 それ以外の場合、攻撃の計画はそのままにしておく必要があります。

多分私はあなたたちがこれをどのように見ているかを誤解しているかもしれません、多分型に保存された関数はちょうど考慮されていませんでした（私はそれらの言及を見つけられなかったので）。 いずれにせよ、確認する価値があると思いました。

ただし、関数適用のアナウンスがtypeofのセマンティックオーバーロードになる場合は、クラスコンストラクターの曖昧性解消と、式レベルの変数の型レベルへの引き上げ（式レベルのtypeofを除く）に加えて、このスレッドの以前のいくつかの質問ですでに示されているように、徐々に複雑になっているように見えます。

編集：ジェネリック型はすでに関数型を返すことができ、ジェネリックも持つことができます。 これは、別の順列がGetFn<A><B>()になることを意味し、最初のジェネリックセットはジェネリック型の呼び出しに属し、後者は関数の呼び出しに属します。 GetFn<A><B><C>()ありませんが、 GetFn<A><B>()<C>()も合法です。 ただし、以前の結論は変更されていません。どのタイプにも関数を含めることができるため、（潜在的に）関数として適用されます。

編集2： X<Y>()に不幸なあいまいさが存在することに気づきました。 これで、 Xは関数型を返す型になります。

• Xが一般的でない場合、これは明らかです- <Y>は関数呼び出しに属します。
• Xが汎用であり、パラメーターが必要な場合、これも明らかです。これは型に属し、関数には型パラメーターが渡されません。
• ただし、 Xにオプションのジェネリックが含まれている場合、これはあいまいになります。
  
  
  
  • ある解釈では、 Xには型パラメーターが渡されますが、関数には渡されません。
  
  
  • 別の解釈では、 Xはデフォルトの型パラメーターを使用するために残されますが、 <Y>は代わりに関数呼び出しをパラメーター化します。
  
  

ここで最善の解決策が何であるかはまだわかりません。

• 1つのオプションは、デフォルトの型パラメーターに完全に依存する型呼び出しを強制して、これをスキップするのではなく、空の<>を明示的に使用することです。 ただし、これは重大な変更になります。
• 別の方法は、代わりにタイプレベルの関数呼び出しにそのような制限を課すことです。これは新しいため、重大な変更は導入されません。 ただし、このアプローチは、式言語と型言語の間で関数呼び出しの構文の間に非対称性を導入するという点でエレガントではなく、直感的ではなくなる可能性があります。

@icholy ：ええ、これらの編集はあなたのポイントをさらに追加しているだけです、私は知っています。

編集3：わかりました。この機能は私のウィッシュリストの一番上にあります。 推論への影響という点で、他のアップグレードはリモートでさえ近づいていません。

@icholy ：要するに、「関数」がジェネリック/タイプにある場合でも、 typeofと書くでしょうか？

これが行われ、オーバーロードと正しく相互作用する場合、関数の戻り型を再帰的に定義できるため、実際には無料で「可変個引数」関数が提供されます（1つ以上のアリティを持つ代わりにカレーされます）。オーバーロードの1つを適用し、ベースケースのオーバーロードをいくつか使用します。 これがHaskellでのやり方であり、TypeScriptにあると素晴らしい機能になるでしょう。

@masaeedu ：面白そうですね。 そして、ええ、オーバーロードは間違いなくこの提案を非常に興味深いものにします-それらは、さまざまなオプションでパターンマッチングを行うために使用でき、 anyフォールバックが含まれています。 これまでのところ、このようなタイプチェックはタイプレベルでは不可能でした。

HaskellよりもRamdaを多用したことを認めます。 しかし、その背景から、カレーは結果を返すか、追加の引数を処理する別の関数を返すかを「知る」必要があるため、通常、カリー化は可変個引数関数とうまく組み合わせられないと思いました。

Object.assignのような可変個引数関数でこのアイデアがどのように機能するかについての擬似コードを示していただけませんか（ &とOverwriteのような詳細をスキップして使用しました）私のPoCでR.mergeAll ）？

@ tycho01私はこのようなコードで遊んでいます：

interface Pop<TVarStack extends VarStack> {
    (a: TVarStack["head"]): Pop<TVarStack["tail"]>
}

interface VarStack<THead = any, TTail extends (void | VarStack) = any> {
    head: THead
    tail: TTail
    <TNew>(a: TNew): VarStack<TNew, this>
    (): (a: Pop<this>) => any
}

// Figure out implementation later :)
let stack: VarStack<void, void>;
const pop = stack(new Date())(10)("Bob's")("your")("uncle")()

// a, b, c, d, and e are well-typed
pop(a => b => c => d => e => {
    // Need this because can't figure out how to encode base-case in Pop recursion
    return stack
})

VarStackは、ある意味で「可変個引数」関数型であり、任意の数の異種引数を指定でき、型レベルで再帰を使用して関連する型情報を忠実に記録します。 残念ながら、TypeScriptは、Haskellと同じように、型レベルでの変換とパターンマッチングを適切にサポートしていません。

typeofにアクセスできる場合、 returnof(overloadedFunction(T))は基本的にパターンを実行する方法を提供するため、 Popのベースケースの問題を解決できます。タイプレベルでのマッチング。

@ tycho01 Object.assignで正確に実行することはできません。これは、前述のように、カレー関数でのみ機能するためですが、大まかに機能するカレーassign関数を作成してみます。同じ方法。

たとえば、 (a: string) => (b: number) => voidがFunc<string, Func<number, void>>の砂糖であり、 (a: string, b: number) => voidがArity<number, Arity<string, void>>の砂糖であるように、型代数を少し一般化してほしいと思います。そんな感じ。 次に、多くの興味深い機能を緊急に取得するために、型を変換するための汎用ツールが必要になります。

トリプルポストについてお詫び申し上げます。 @tycho01これがカレーの「可変個引数」 assignです：

interface Assign<TCurr extends {} = {}> {
    <TAdd extends {}>(a: TAdd): Assign<TCurr & TAdd>
    (): TCurr
}

let assign: Assign = undefined // implement somehow
const result = assign({ foo: "bar" })({ baz: 42 })()

@masaeedu ：ええと、それはレデューサー関数を持っているようなものだと思います:)ですが、可変個引数（？）以外の引数もあると、その部分はもっと難しくなる可能性があります。

私はそのアイデアが好きです。 私は間違いなくインターフェースの方向についてあまり考えていませんでした。
ただし、タイピングのJSを変更できる場合は、TC39にObject.assignを非可変個引数のmergeAllに変更するように依頼します。 ：D

これまでのところ、実際に関数で機能していたような増分ベースの反復とは異なります（＃17086）...しかし、どちらにしても、この提案は、これまでに見たどの提案よりも大きな影響を及ぼします。

@ tycho01 JS（または少なくとも既存のJSエンジンとコード）のカレー関数または繰り返し適用には実行時コストがかかるため、可変個引数関数を固定アリティ関数に変換するように要求した場合、大きな牽引力を得る可能性は低いと思います。おそらく高度に最適化されていません。 代わりに必要なのは、TypeScriptを使用して、arity>1関数の型を再帰的に構築および分解することを同様に簡単にすることだと思います。 これはすべて＃5453に戻ってくると思います。

他の人は、c ++が非常によく似た機能を持っていることを学ぶのが面白いと思うかもしれません： decltype（expression）

この機能はTypeScriptに組み込まれる予定ですか？
引数が式である元の提案された形式を非常に好みますが、式の位置に型を含む特別な構文を持つというTSチームの意図は、すべてを複雑にし、言語に到達するのを遅らせます。
このトピックを維持する必要があります。

この提案のサブセットさえも実装できれば本当に嬉しいです。 つまり、この単一のもの：
type A = typeof anotherVariable 。 この一行で何でもできます。 interface B extends A 、 <B & A> : B & Aなど

私はReactでこの種のものの多くのユースケースを見ています。 高次のコンポーネントを作成する場合、それが現在HOCであることをコンポーネントクラス宣言に示唆することははるかに困難です。

私がやったことは、2つのクラスを作成することです。 1つのクラスがReact.Componentを拡張し、すべての追加メソッドを追加し、HOC関数内のクラスがrender()を操作します。

@blindbox type A = typeof anotherVariableはすでに機能します：

var data = [1, 2, 3].map(v => ({ raw: v, square: v * v }));

function checkItem(item: typeof data) {
    // item is Array<{ raw: number; square: number; }>
}

@Igorbekうわー、その通りです。

さて、私はそれが私の側でうまくいかなかった理由を理解しました。
これは機能しません

interface B {
  thisIsB: boolean
}

const typeTest = (type: any) => {
  return 1 as any as App & B
}
type A = typeof typeTest(1)
declare const aVal: A; // aVal's type isn't of type App & B, but something else.

ただし、これは機能します。

interface B {
  thisIsB: boolean
}

const typeTest = (type: any) => {
  return 1 as any as App & B
}
const typeTestVal = typeTest(1)
type A = typeof typeTestVal
declare const aVal: A; // aVal's type is of type App & B!

そうですね、問題は、ジェネリック型の引数を使用する必要がある場合など、特定のユースケースでは使用できないことです。

function someFunctionWithComplexReturnTypeThatUsesGenerics<T>(item: T) { ... }

// it is impossible to work this around because there's no chance to create a fake variable that would be parameterized by T
function use<T>(item: typeof someFunctionWithComplexReturnTypeThatUsesGenerics<T>(item)) { ... }

@Igorbek ：

引数が式である元の提案された形式を非常に好みますが、式の位置に型を含む特別な構文を持つというTSチームの意図は、すべてを複雑にし、言語に到達するのを遅らせます。

それで、彼らがそれを書いたので、私たちは文字列と数字のリテラルを手に入れました。つまり、物事は少し曖昧になっています-それらはどちらの方法でも機能します。 リテラル配列とオブジェクトも同様にタイプ表記に似ているため、これまでのところ良好です。

したがって、変数、ジェネリック、その他のタイプなどの値/タイプも格納されています。 物事が役立つためには、ここでこれらの一部を受け入れる必要はありません。
ここでのタイプベースのアプローチの良い議論は、この混合物をタイプレベルで無料で許可することです。 つまり、型レベルではすでにtypeof myVarと言うことができます。つまり、この関数'application'を型レベルに追加すると、格納されている型と通常の変数の両方を自動的にプラグインできるようになります。 。

最初に提案されたアプローチについてのあなたのさらなる考えを見てみたいと思います。 確かに、それはタイプレベルにもう少し公開するのに役立つかもしれません：JSベースの演算子（ ! && || + -を考えてください* / instanceof ）およびTypeScript固有の演算子（アサーション演算子! ）。
これらのJS演算子についてのことは、次のようなものです...リテラルを操作して、対応するリテラル結果タイプを生成できるようにすることは、現在スコープ外と見なされているため、現状ではタイプレベルではかなり役に立ちません（ ref ）--expression -レベル1 + 1は、タイプnumberを生成するだけで、他のタイプも同様です。
これを念頭に置いて、私は彼らのタイプベースの提案に少し落ち込んでいます。

この機能はTypeScriptに組み込まれる予定ですか？ [...]このトピックを維持する必要があります。

私はこの提案をここでのより小さな症状に対するより一般的な解決策として提案しましたが、成功は限られていました。

@ tycho01 typeofの式ベースのバリエーションに関する私の議論は、@ yortusが最初に述べたものとほぼ同じです。

• 一貫性：既存のtypeof （型の位置にある）はすでに式を処理していますが、単一のシンボルを受け入れるように制約されています。 そのため、型または疑似呼び出しを受け入れると、（式と型に加えて）はるかに別の構文ブランチであるはるかに面倒な構文が導入されます。
  
  
  
  • ユーザーは新しい構文を学ぶ必要はありません
  
  
• シンプルさ：TypeScriptには、この機能を目立たない方法で実装するために必要なすべての機能がすでに備わっているようです（PRによって証明されています）
• 完全性：式は、常に型アサーション（ (undefined as any as <any arbitrary type can be here>) ）を使用できるため、少なくとも型と同じ表現力を持ちますが、型システムには、式で表現できる型がない場合があります（spread型とrest型は後に導入されました）対応する表現が上陸しました）。

そのポイントをpromised PRに持ってきてくれてありがとう@tycho01 （私は実際にあなたのコメントの後にここに来ました）、それは本当にそのような単純で一般的な機能がベーキングなしで非常にエレガントな方法ではるかに複雑なシナリオをカバーできる方法を示しています言語への非常に特定の振る舞いで。

拡張されたtypeofは、型システムの表現力の本当のゲームチェンジャーであり、マップされた型のように見えます/ keyofはそれを行いました。

@Igorbek ：詳しく説明してくれてありがとう、それからあなたがどこから来ているのかわかります。 おそらく、これら2つのアプローチは、異なるユースケースに役立ちます。

現在のTS（またはPlaygroundの2.3.3 ）は、元のシナリオの多くをすでに機能させることができるため、元の投稿よりも元の提案の今日の価値をよりよく示していると思います。

// I have a strongly-typed collection but the element type is anonymous/unknown, how can I reference the element type? (#3749)

// Mapping to a complex anonymous type. How to reference the element type?
var data = [1, 2, 3].map(v => ({ raw: v, square: v * v }));
declare function checkItem(item: typeof data[0]): any
// ^ no longer errors, needs no further change

// A statically-typed dictionary. How to reference a property type?
var things = { 'thing-1': 'baz', 'thing-2': 42 };
type Thing2Type = typeof things['thing-2'];
// ^ no longer errors, needs no further change

// A strongly-typed collection with special indexer syntax. How to reference the element type?
var nodes = document.getElementsByTagName('li');
type ItemType = typeof nodes.item(0);
// ^ the `.item` access works, but function applications still errors, would be fixed by either version of the proposal.

// A function returns a local/anonymous/inaccessible type, how can I reference this return type? (#4233, #6179, #6239)

// A factory function that returns an instance of a local class
function myAPIFactory($http: HttpSvc, id: number) {
  class MyAPI {
    constructor(http) {}
    foo() {}
    bar() {}
    static id = id;
  }
  return new MyAPI($http);
}
declare function augmentAPI(api: typeof myAPIFactory(HttpSvc, number) /* ERROR */): any
// ^ function applications errors, would be fixed by either version of the proposal, if using slightly different syntax.

// I have an interface with a complex anonymous shape, how can I refer to the types of its properties and sub- properties ? (#4555, #4640)

// Declare an interface DRY-ly and without introducing extra type names
type MyInterface = {
  prop1: {
    big: {
      complex: {
        anonymous: { type: {} }
      }
    }
  },
  // prop2 shares some structure with prop1
  prop2: MyInterface['prop1']['big']['complex'];
}
// ^ no longer errors after swapping `.k` access to `['k']`. `typeof` was unnecessary and counter-productive -- MyInterface isn't exposed on the expression level.

これらの例は、式または型のアプローチのどちらにも当てはまらないと思います。ほとんどは廃止されており、簡単な関数の適用はどちらかによって可能になります。

確かに、tinganhoが焦点を当てているタイプレベルベースの関数適用では、TSチームと私は、 typeofを介して式変数を公開できますが、ご指摘のとおり、タイプレベルは、式で公開される機能よりも遅れる傾向があります。レベル。 この関数適用自体とあなたが言及したスプレッド構文は明らかに主要な例であり、私はそれらが対処されることを絶対に望んでいます。 おそらく、現在のギャップの多くはここで取り組むことさえできます。

同様に、式優先のアプローチでは、 <MyType> whateverまたはwhatever as MyTypeを使用して型を挿入することもできますが、型アプローチのtypeofと同様に、後付けのように見えます。質問タイプ/ジェネリックスに格納された関数の適用については、そのタイプベースのアプローチの実際の付加価値の大部分を補う可能性があります（ここでは言及されていませんが）-高階関数の正確な推論、およびタイプベースの条件文そのpromisedスレッドのように。*さらに悪いことに、OPのユースケースとは異なり、これらには回避策がありません。

アイデアが衝突する場所がわかると思います。現在の提案では、 typeofキーワードがその式を値レベルに切り替えるかどうかについて、（私の解釈では） typeofをそのままにしておくかどうかについて矛盾した見解があります。 、ただし、型レベルで関数適用構文を公開します。

私の見解では、矛盾は多少偶然です。 私はどちらのユースケースの正当性も無視しません。 両方を実装する場合、セマンティクスの衝突を回避する追加のキーワードを確認できます。 キーワードがどうなるかは正直無関心です。たわごとを入力したいだけです。

*：ジェネリックスで型をキャプチャするのではなく、パラメータ内の関数をパラメータ名で参照することで、おそらく高階関数を使用することに気づきました。
実際には、物事は両方向に変換できるようです。 typeofは値レベルから型レベルに持ち上げるのに役立ち、 declare let y: x;は物事を値レベルから型レベルに持ち上げるのに役立ちます。 OPの回避策のようにエレガントではありませんが、そうです。
関数型がたとえば明示的なジェネリックスを介して持ち込まれた場合、これは役に立たないと思います-それらを移動する方法がなければ、型レベルになります。
それが私が先制的に機能の基礎をカバーすることを望んでいるように聞こえるなら、それはおそらく未解決のタイピングの課題に関する私の進歩の多くがこの1つのアドオンでブロックされたためです（5453に注目してください）。 しかし、これらのことを理解できれば、それだけの価値があります。

編集：式ベースのアプローチで除外される可能性のあるいくつかの理論的なケースについて考えましたが、実際の出来事はまだ頭に浮かびませんでした：

• 明示的に提供されたジェネリックを介して渡される関数。
• パラメータ関数によって返される関数。ジェネリックにキャプチャされます。つまり、（式ベースの提案の構文を使用して） declare function f<G extends (...args: any[]) => R, R extends <T>(foo: T) => Bar<T>>(g: G): typeof R(baz); // error following the expression-based proposal: R is not exposed at the expression level 。 もちろん、これらは、 Gのパラメータタイプを知っていて提供できれば計算できますが、これまでのところ、この情報を取得する方法はありません（おそらく＃14400？）。 このカテゴリには、上記のAngularJSで使用されているファクトリ関数で動作する関数が含まれると思います。

@Igorbekこのスニペットであなたが何を期待しているのかわかりません：

function use<T>(item: typeof someFunctionWithComplexReturnTypeThatUsesGenerics<T>(item)) { ... }

循環定義のようです。

@masaeedu申し訳ありませんが、私は意味しました：

（ someFunctionWithComplexReturnTypeThatUsesGenerics ＃$ではなくfに切り替えます）

function use<T>(item: typeof f<T>(undefined as any as T)) { ... }

念のために言うと、これは現在、偽の変数を導入することで回避できないことです。

const _typeofItem = f<T>(undefined as any as T); // no T here
function use<T>(item: typeof _typeofItem) { ... }

ところで、 typeofの方が優先度が高いため、現在の提案がメンバータイプのクエリタイプ演算子T[K]と競合していることに気づきました。

• typeof x[K]現在、 (typeof x)[K]を意味します。ここでKはタイプです
• 式ベースのバリエーションを使用すると、あいまいさが発生します。
  
  
  
  • typeof x[k]は(typeof x)[k] $を意味します。ここで、 kはタイプです。 また
  
  
  • typeof x[k]はtypeof (x[k]) $を意味します。ここでkは式です。
  
  

$＃$ 11 $＃$は意味的に同等であるため、実際にはtypeof (x[k])を好みますが、確かに重大な変更です。

Chromeの開発ツールを使用したところ、メンバー演算子の方が優先されていることがわかりました。 どこで見つけましたか？

@Igorbek ：ええ、それが元の投稿のtype Thing2Type = typeof things['thing-2'];がすでに機能している理由のようです。

@dehli ：JS式レベルをTSタイプレベルと比較しています-それらは同じではありません。 1つはブラウザ/ノードで実行され、もう1つはTSコンパイラで実行されます。

個人的には、TypeScriptがインデックス付きの型アクセスよりも高い優先順位で型レベルのtypeofを解決するのは奇妙だと思います。 正直なところ、それは私にはほとんどバグのように見えます。 （そのケースは実際にテストされているのだろうか。）

@tycho01ガッチャ。 TSはJSと同じ優先順位を使用すると思いました。

@dehli発現レベルは同じです、ええ。 型レベルでは、構文は似ていますが、文字列ではなく型を返すというものです。

優先順位は、彼らが想定していた制限の結果かもしれないと私は推測しています。 その機能を拡張する場合、これらの考慮事項はもはや賢明ではないように思われるかもしれないことを認めます。

別の注意点として、提案の両方のバージョンが実装される場合、括弧は、そのためにどのレベルにあるかを明示的に保つための効果的な方法としても役立ちます。 妥協のように聞こえないものを思い付くのに苦労していますが、そうです。

@Igorbekこれは、任意の式でのtypeofの主な残りのユースケースですか？ ＃14400を取得した場合、私が間違っていなければ、プレーンなユーザー定義型を使用してreturnofが得られます。

14400は、一般的な形式でreturnofを提供しません。

type Return<T extends () => R, R = any> = R;

// overloaded function
declare function f(item: number): number;
declare function f(item: string): boolean;

type fType1 = Return<typeof f>; // ??
type fType2 = typeof f(1); // number
type fType3 = typeof f('a'); // boolean

// generic function
declare function g<T>(item: T): T;

type gType1 = Return<typeof g>; // ??
type gType2 = Return<typeof g<number>>; // not supported syntax
type gType3 = typeof g(1); // number
type gType4 = typeof g<number>(1); // number
type gType5 = typeof g('a' as 'a'); // 'a'

私は残りのすべてのユースケースを認識していません。それらはまだ発見されていないようですが、私にとって最も無敵で魅力的なのは次のとおりです。

• typeofは標準の過負荷解決を使用するため、_条件付きマップタイプ_は＃12424で取得できるよりもはるかに強力です。 @ tycho01は、 promisedタイプのエレガントな例を示していますPR＃17077
• 関数/メソッドの型を取得すると、ジェネリック型のコンテキストで返されます（前に示したように）

@masaeedu ：いい質問です。 短いバージョンは、 @Igorbekが言ったこととほぼ同じです。 解決された具体的な課題のもう少し詳細については、＃16392の「必要な主な機能」リストに短いリストがあります。ここでは、未解決の課題をそれらを可能にする可能性のある提案に結び付けようとしました。

これも：

• AngularJSなどで使用されるようなファクトリ関数。元の投稿でリンクされている3つのスレッドを参照してください。 -現実的には、新しく組み込まれたReturnTypeを考えると、これで問題ないはずです。
• 既知の入力が与えられると、 reduce / map / filter / findのようなものの正確なリターンタイプを突然計算できます-反復とチェックを含むもの。 stdlib.d.tsはそこでメリットがあり、Ramda/LodashのようなFPライブラリもメリットがあります。 実際には、すべての入力がわかっているわけではありませんが（タプルよりもリストのような配列）、オブジェクトに対するmapおよびfilterの操作は、 Partialよりも適切に入力できます。 これは、redux（https://github.com/piotrwitek/react-redux-typescript/issues/1を参照）やAngularのngrxなどの状態管理ライブラリをより適切に入力するために必要です。適切に型指定されたmap操作がないと、DRY'erの入力データから型レベルで目的の結果を計算する方法がないためです。
• 現在、関数合成の型指定では、入力に依存する戻り型も考慮に入れることができません。
• 突然、レンズのようなものをタイプし始めることも実行可能になります。 -技術的には、これは入力に依存するリターンタイプを使用した編集操作でのみブロックされていると思います。 本当に贅沢です。 ただし、タプルの変更には＃5453（の一部）が必要です。
  また、次のことが可能になります。
• これまで不可能であった型レベルでのブールリテラルの操作
• flatMapのような操作のアンラップタイプそのpromisedプロポーザルなど
• 型/関数の入力に制約を追加する、＃15347のトピック、および依存型に関する本「Idrisを使用した型駆動型開発」から得たアイデア。 これは、 0除数を禁止すると言うのに役立つ可能性があります。これは、基本的に、＃4183のトピックである型から減算するためのハックです。 まだほとんどのユースケースを想像していないと思いますが、これで実現できます（例： function div<B extends number, NotZero = { (v: '1') => 'whatever'; }({ (v: 0) => '0'; (v: number) => '1'; }(B))>(a: number, b: B) 。 通常、Idris言語は、長さに対して安全なベクトル/行列演算でアドバタイズしますが、これが必要なのは高階関数の場合のみです。
• 上記の制約+ IsUnionを使用して、入力タイプのUnion<T> / NonUnion<T>制約を表現する方法。 -そのタイプのソータは壊れました、そして私はもうこれについてどうやって行くのかわかりません。
• ＃5453も指定すると、これはcurry 、 Function.prototype.bind 、 Promise.allなどの関数の入力にも役立ちます（完全なリストではなく、他の人が挑戦的なものとして挙げた関数の一部です）。
• ＃13500で提案されたswitchロジック、ここでは関数のオーバーロードパターンマッチングによって解決されました
• ＃12424および＃17077（ promised ）のトピックであるマップされた条件付きタイプ、別名タイプレベルのタイプチェック。 しかし、それはそれを解決しません-それが今日どこでもブールリテラルを生成するために使用可能であったとしても、この＃6606が着陸するまで、タイプレベルでそのようなブールリテラルに基づいて条件を操作/実行する方法はまだありませんでしたとりあえず。
• 操作間でこれを保持するなど、オブジェクトタイプに文字列インデックスが存在するかどうかを確認します（＃12215のOmit 、 Overwriteなど）。＃12424のコメントを参照してください。
• 上記の文字列インデックスチェックに基づいて、オブジェクトプロトタイプメソッドの名前に一致する文字列のチェック（例： toString 、 toLocaleString ）が文字列インデックスに解決されるようにオブジェクトタイププロパティアクセスを修正する方法プロトタイプメソッドよりも、以前はグリッチされた組み込みオブジェクトプロパティアクセスに依存していた他のすべてのタイプの操作で、 toStringオブジェクトアクセスに関連するグリッチを修正する可能性があります。

編集：執筆時点以降、条件付きタイプ（＃21496）で埋められたユースケースを取り消しました。

@Igorbekの式優先アプローチの提案は（上記のリストの一部のいくつかの未知のアプリケーションを壊す可能性を犠牲にして-隅に塗りつぶされるのが怖いのですが、具体的なことはまだ考えていません）さらに、値レベルと型レベルの間のギャップを埋めることを約束します。これには、現在、この関数アプリケーション（this＃6606）、spread / rest（＃5453）、アサーション演算子! （＃17370）、共用体タイプなどが含まれます。タイプガードによる減算（＃4183、それ以外の場合は上記の制約によって達成可能）、そしておそらくもっと頭のてっぺんから考えることはできません。

この全体的なトレードオフにより、2つの方法（実際のタイプレベル、タイプレベルに埋め込まれたアクセスされる式レベル）ですべての同じ機能にアクセスできるようにする理由など、いくつかの疑問が生じる可能性があります。

編集：追加の潜在的な課題で上記の私の比較コメントを更新しました。

編集2：

ここで残念なのは、元の投稿では、 null &の回避策がなくても、一部のエッジケースを記述できると信じていることですが、実際には、これは、周囲のコンテキストに対する既知の回避策がなく、現在TSを抑制している重要な機能です。 。

つまり、個別の.d.tsファイルに書き込まれたTSに影響します。これは、 stdlib.d.tsだけでなく、元のJSプロジェクトとは別に書き込まれたすべてのDTタイピングの標準であり、変更される可能性はほとんどありません。一方、JSライブラリは、フローなどの代替手段に対してもオープンであり続けたいと考えています。

（これは.tsの型付けにはあまり適していません。つまり、OPの「回避策」を使用する型は、式レベルに影響を与えずに、より高いレベルの再利用可能な型に構成するなど、パラメーター化できません。）

@tycho01リストをありがとう。 そこには私が消化する必要のあるリンクがたくさんあります。 タイプのパターンマッチングも本当に必要です。＃6606は、この問題に対する優れた実用的なソリューションです。 ただし、値レベルとタイプレベルで物事の間に混乱が生じているように思われ、＃6606はこの領域で物事を改善しません。

この機能が必要な理由は、以下に対応する型式を作成する方法がないためです。

• 特定の型の引数とともに適用された場合の関数型の戻り型
• （ typeof K[L]の前）文字列リテラル型のキーに対応するオブジェクト型のプロパティの型
• （おそらく他の人、私はあなたのリストをもっと詳しく調べる必要があります）

値レベルの構成と型レベルの式を混ぜ合わせることなく、これらの純粋な型レベルの式を実際に構成できるはずだと思います。 (a: A) => BやA | Bのような型が、 Func<A, B> 、 Union<A, B>のような単純なパラメーター化された型の砂糖であり、パラメーター化された型を操作するための一般的なツールがあればいいのですが。 （HKT、fundepsまたは型族など）。

健全性に過度に焦点を当てることがTypeScriptの目標の1つではないことは知っていますが、不透明な方法で相互作用するタイプレベルの概念がたくさんあります。 タイプとは何かのある種の形式化、およびタイプが他のタイプとどのように相互作用するか（サブタイピング、破棄など）の機械的ルールを規定する方法は大いに役立ちます。

値レベルの構成と型レベルの式を混ぜ合わせることなく、これらの純粋な型レベルの式を実際に構成できるはずだと思います。

そうそう、私は個人的に、価値レベルの構成要素を使用することにまったく頼るつもりはありませんでした。これが私が試みているすべてです。 価値のレベルが不可欠だったとしたら、私はここで表現ベースのキャンプにいたかもしれません。 ：P

値とタイプレベルの間のギャップはほとんど狭くなると予想され（TC39はTSよりも速く移動しますか？）、ギャップにはすでに優れたタイプレベルの提案があります（以前の投稿の下部を参照）。

ちなみに、かなりの数の関数の型指定を作成することは、ほとんどのユーザーの経験の範囲外になるだろうと私は理解しています。
私の見方では、標準ライブラリとFPライブラリを適切に入力して、TSユーザーがそれらを記述し、推論で自動的に処理できるようにする必要があります。
TSにはタイプレベルの演算子がいくつかありますが、実際の問題を解決すること（主な例は＃12215のOverwrite / Omit ）は、カジュアルなWeb開発者にとってロケット科学に少し足りないように思われるかもしれません。 ちなみに、それは最近まで私たちを連れて行ってくれました、そしてそれらはまだプロトタイプ/インデックス/シンボルプルーフでさえありません。

（a：A）=>BまたはA|のようなタイプがあればいいでしょう Bは、Func 、Unionなどの単純なパラメーター化されたタイプの砂糖でした

それを裏返して、パラメータ化された型をエイリアス/型構築子として作成できます。 Foo<Bar>をとる型操作では、単純化されたものであるかどうかは関係ありません。説明に適合するかどうかをチェックするだけです。
これはstdlib.d.tsとほぼ同じです。 foo[]がありますが、 Array<Foo>の説明を満たしているため、 Array.prototypeの型で機能します。
しかし、実際にはそうではありません。

type Union2<A, B> = A | B;
type TuplizeA<Tpl extends Union2<any, any>, A, B> = [Tpl[0], Tpl[1]];
// ^ sorry, no way to access union members through e.g. [0]
// type a = TuplizeA<1 | 2>;
type TuplizeB<Tpl extends any | any> = [Tpl[0], Tpl[1]];
// ^ sorry, no way to access union members through e.g. [0]
// type b = TuplizeB<1 | 2>;
type TuplizeC<Tpl extends Union2<A, B>, A, B> = [A, B];
type c = TuplizeC<1 | 2>;
// ^ need 3 arguments, maybe fixable with #14400
type TuplizeD<Tpl extends A | B, A, B> = [A, B];
// ^ need 3 arguments, maybe fixable with #14400
type d = TuplizeD<1 | 2>;

そうですね、まだ解決していませんが、kubeの＃14400が実際に役立つことに気づきました。 そして、私は今日も早くあなたに会いました！
実際の関数についても同じことが言えます。これは、＃14400が関数の戻り型だけでなく、パラメーターの型も実行する可能性があることを思い出してください。

このアプローチでは、今のところオーバーロードを使用する必要があります。これは、拡張性がないため残念ですが、そうです。 再び一般的にするために、基本的にこれらの＃6606パターンマッチングオーバーロードを使用して、さまざまなアリティに対して適切なオプションをトリガーします。
これを使用して、それらを一般的にタプルタイプに変換し、増分アプローチを使用してそれらを反復処理して、何らかの方法でそれらを操作できると思います。
ユニオンの場合、タプルタイプに変換するためのよりきれいな方法を望んでいました。 ただし、任意の順序が追加され、きれいな構文/キーワードも考えられません。

編集：これらの式/タイプレベルの機能のギャップをもう一度確認するには：

• 関数適用：これ＃6606
• アサーション演算子! （＃17370）：この＃6606の後、これは解決されます
• タイプガードによる共用体タイプの減算（＃4183）：上記の!の一般的なケースであり、この＃6606は制約（たとえば、上記のNotZero ）でも実現できます。
• Spread / Rest（＃5453）-タプルが着地するまで操作できない場合でも、同様のArrayLikeは操作できます。私の要点で、 Listの操作を参照してください。 この＃6606を使用すると、適用されていない関数からparamsを抽出できると思いますが、適用時に（つまり、正確な入力値を取得するために）抽出するには、5453が必要です。

要するに、この提案が上陸したとしても、表現レベルと型レベルの間の機能のギャップは、ここでの表現フレーバーの提案に対してそれほど大きな議論にはならないでしょう。 5453も入っていたら、もう何も思いつかなかった。 また、まれな例外については、ここの元の投稿に記載されている回避策が引き続き有効であることに注意してください。

さて、それでも簡単にできる議論は、式フレーバーのバリアントでは、型レベルがミラーリング演算子に追いつく前であっても、この機能はJSと同じ構文で公開される（回避策なし）ということです。学習曲線を減らす。

編集2：

型を式レベルに持ってくるという式提案のトリック1 as any as MyTypeは、関数自体でも論理的に機能するはずだと気づきました。

これはおそらく、両方のフレーバーによって有効になる実際の機能がいくぶん似ているように見えることを意味します。外見上の違いは、関数適用で変数を使用するためのtypeof myVar （タイプフレーバー）とmyVar （式フレーバー）で構成されます。 それらのタイプを使用するには、 MyType （タイプフレーバー）と1 as any as MyType （式フレーバー、代替declare let a: any; 、次に<MyType>a ）。

どちらのASTの変更もかなり扱いやすいようです。 式フレーバーは、代わりに値式を指すためにtypeof結合が必要です。 タイプフレーバーは、既存の関数適用構文（ fn<T>(arg) ）を式からタイプレベルにコピーし、上記のRyanによって提案された既存の実装にフックします。

私はそれが次のようになると思います：

表現フレーバーの場合：

• TSタイプレベルのサポートに先立つ回避策なしのJS構文を使用したtypeof expr

タイプフレーバーの場合：

• 優先順位に対する重大な変更はありません
• 値の式は、回避策を通じて（または、演算子が追いつくまで異なる構文の場合はTSを通じて）キャプチャ可能です。
• MyType 1 as any as MyType ：式レベルのタイプレベルに式レベルのタイプレベルがありません。

ここでこれまで触れられていない関連トピックの1つは、この型レベル関数「アプリケーション」でthisバインディングを提供する方法です。 現在、JSはこれをFunction.prototypeメソッドに上書きすることを委任していますが、現状では、これらはタイプレベルでこれを処理する方法を欠いています。

F(MyA, MyB) ： F(this: MyFoo, MyA, MyB)として呼び出された可能性のある関数型F (this: Foo, a: number, b: string) => SomeReturnTypeが与えられた場合の、ランダムな構文例。

thisバインディングを上書きせずに戻り型を計算すると、 F(MyA, MyB)のようになります。これは、でこのような関数を使用しようとすると、型レベルのthis引数が通常無視される方法を反映しています。表現レベル。

この構文例の長所：

• 宣言構文をミラーリングします

この構文例の短所：

• 宣言構文をミラーリングします

だから、これはすでにその言語になっています！

興奮しすぎないでください。

@DanielRosenwasserは、型の代わりにリテラルの関数呼び出しを使用できるようにするバグである＃12146を指摘しました。

_5分後_

タダー！ 私たちが本番環境で決して使用してはならない恐ろしい邪悪なもの。 しかし、それは魅力的です...

interface String {
    passthrough<T>(v: T): T;
}

// All work
type ANumber = "".passthrough(10 * 10);
type AString = "".passthrough("hello" + "world");
type AHelloWorld = "".passthrough("hello world");
type AnArbitraryThing = "".passthrough(Object.assign({hello: "world"}, {foo: "bar"}));
type ThisCraziness = "".passthrough((() => "cows are big dogs"));

〜そのため、この問題のEffort: Difficultは少し疑わしいように見え、あちらで偶然にそれを行ったように見えます。

@tycho01をお楽しみください。

@TheOtherSamP TypeScript 2.4.2でこれを試しましたが、これらのタイプはすべてanyであると推測されます。

@pelotomええと、2.4.2と2.5.0で動作しています-dev.20170803。 es6およびstrictモードをターゲットにします。

彼らはちょうどそれを修正したように見えます、私はそれが私のせいかもしれないのではないかと心配しています。 ＃17628

@TheOtherSamPいいえ、サイコロはありません。 しかたがない。

@pelotomそれは奇妙なことです、それは私にとって完全に新鮮なプロジェクトで働いています、私は私たちのセットアップについて何が違うのかわかりません。

@TheOtherSamP ：はは、それはかなり面白いです。
時間的には、コメントの少し前に修正を開始したようです。 しかたがない。

@pelotom ：

TypeScript 2.4.2でこれを試しましたが、これらのタイプはすべて任意であると推測されます。

彼のスニペットはPlayground（2.3.2）で機能しているようです。 それ以外の最近のバージョン（ ^2.5.0-dev.20170626 ）では、私も再現に問題があります。

そのため、この問題のEffort: Difficultは少し疑わしいように見え、あちらで偶然に行ったように見えます。

彼らは型ベースの実装を参照していましたが、これはいくつかの変更を意味しますが、これは式言語を使用しているようです（-> + 、 Object.assign 、さらなる関数呼び出し）。

@ tycho01 ＃17618で注目を集めたことから、すべてが始まったと思います。 まあ、それは私にそれを本番環境で使用することを半真剣に検討することを教えてくれます。

彼らはタイプベースの実装を参照していましたが、これはいくつかの変更を意味しますが、これは式言語（-> +、Object.assign、さらなる関数呼び出し）を使用しているようです。

ええ、私はばかで、それを言うまでこの問題全体を読み通しませんでした。 残念ですが、おそらくこの機能のより良いバージョンですが、今すぐ入手できればと思います。 私は型システムの限界を大いに押し上げます、そしてこれか＃12424のどちらかが非常に多くのオプションを開くでしょう。

＃17961でPRを開始しました。

@yortusこれは「typeofliteral」のケースをカバーしていますか？
今日のTypeScriptでは、「const x：typeof 1=1;」と書くことはできません。

@NN ---元の提案はすべての式をカバーしていますが、私が理解しているように、「承認された」部分はプロパティアクセスと関数の戻り型のみをカバーしています。

typeof 1が許可されていたとしても、リテラル型（ 1 ）またはより広い型（ number ）のどちらを提供するかはわかりません。

今日のTypeScriptでは、「const x：typeof 1=1;」と書くことはできません。

なぜconst x: 1 = 1;ないのですか？

@SaschaNaz私は次のようなものを書きたかった

const a = {q:1};
const b = {q:1};
const x: ReadonlyArray<typeof a> = [a,b];

しかし、同様のことはリテラルでは機能しません。

const x: ReadonlyArray<typeof 1> = [1,2,3];

@yortus正確なタイプについての良い点。 リテラル型については考えていませんでした。

@ NN ---：あなたの例はすでに機能していると思います。

@ tycho01フローに$Callタイプが追加され、関数のリターンタイプを取得できるようになりましたhttps://github.com/facebook/flow/commit/ac7d9ac68acc555973d495f0a3f1f97758eeedb4

typeof fn(...)のみを許可することは、任意の式のtypeofを許可することと同じではないでしょうか。

function fn() {
  return /** whatever expression you like */;
}
type a = typeof fn();

タイプを把握する以外の目的でランタイム関数を作成している場合を除きますか？

あまり。 式の実行ではなく、式の型評価を行っています。

@ dyst5422 typeof fn()は実際には式を評価せず、リターンタイプを提供するだけです。

編集：多分それはあなたが言おうとしていたことです、確かではありません。 しかし、 @ sky87は、関数を_評価_するのではなく、型式で使用する以外の目的で関数を_defining_することについて話していたと思います。

@ dyst5422 、@ pelotomが言ったように、私はあなたが関数を実行するという意味ではありませんでした。 さらに詳しく説明すると、任意の式のtypeofは許可しないが、関数の戻り型のtypeofは許可する場合、より複雑な型を理解するために私は何をしますか式はそれらを関数でラップすることで、その戻り型を要求できます。 これにより、実行時に関数が作成されますが、それは戻り型を取得するためだけのものであり、作成するのはより定型的です。

編集：あなたは実際にすでに任意の式のタイプを理解することができます、これは醜いですが機能します

const dummy = (false as true) && /* arbitrary exp */;
type TypeOfExp = typeof dummy;

正直なところ、どのハックを好むかわかりません。 typeofを使って直接タイプを尋ねられるのが一番いいと思います。

ああ、私は今フォローします。 ええ、私はそれを次のように使用できるようにすることが好ましい方法だと思います

type TypeOfExp = typeof (
  false &
  "false" &
  0
)

式型評価を任意に行えるようにする

new呼び出しの戻りタイプを照会することは可能ですか？ 私のユースケース： PromiseConstructorLike実装（$ qやBluebirdなど）への参照を受け入れ、その実装によって構築されたPromiseを返す関数の型アノテーションを記述したいと思います。

declare function wait<P extends PromiseConstructorLike>(time: number, implementation: P): typeof new implementation<void>((res: any, rej: any) => void);

const bluebirdPromise = wait(1e3, Bluebird);
// typeof bluebirdPromise should be instance of Bluebird

typeofなしで返品タイプを照会することは可能ですか、それともnull as FnTypeにする必要がありますか？

interface Fn {
    (a: string): string;
    (a: number): boolean;
}
type Ret = Fn(number); // Ret = boolean
type Ret = typeof (null as Fn)(number);

これらの質問がすでに回答されている場合は申し訳ありません。 見つかりませんでした。

ここでのnewのポイントは何ですか、 typeof implementation()だけが必要ではありませんか？

いいえ、 implementation()は有効な呼び出しではないためです。 PromiseConstructorLikeは、型宣言に従って、 newを介してのみ呼び出すことができます。 typeof implementation()はタイプエラーであり、 (typeof implementation)['foobar']がタイプエラーであるのと同じです。

遊び場リンク

FlowTypeが行ったような推測可能なジェネリック型を導入することは可能ですか？ 少なくとも、関数の戻り値の型を取得するための問題を解決できます。

type _ExtractReturn<B, F: (...args: any[]) => B> = B;
type ExtractReturn<F> = _ExtractReturn<*, F>;

@Cryrivers ：そのアプローチについては＃14400を参照してください。 ただし、出力タイプが入力に依存するという問題は実際には解決されません。

関数の呼び出しが動的に何を返すかを示唆するために、今日もこれが必要になりました。それが優先されることを願っています。

ReturnType<T>演算子は、条件付きタイプを利用して、TS 2.8のlib.d.tsに追加されています。

ReturnType<T>は、引数の型に依存する戻り型をまだ考慮していないため、参考のために、Flowの$Call型の実装を示します。

編集：申し訳ありませんが@goodmind 、私はあなたがすでに正確にそれにリンクしていることに気づいていませんでした。

最近のTSの追加に基づいて、この提案のユースケース（またはそのタイプコールの解釈）の以前の投稿を更新しました。
パターンマッチングのユースケースは＃21496でカバーされるようになり、ユーザーが提供するラムダに基づいて型を計算したい場合、たとえばcurry 、関数合成、 map 、 reduce 、ラムダに基づいたレンズ編集...楽しいもの。 :)

PS @ thorn0 ：AngularのユースケースはReturnType （＃21496）で埋められると思います！

この表現を許可することで、これをカバーする必要があります。
prop2：typeof this.prop1.big.complex;

@mhegazyこれを追跡するための別の問題はありますか？
静的プロパティで機能しているのに、typeofがローカルでは機能するが、プロパティでは機能しないのは面倒です。

class A {
    x: number;
    static y: number;
    f() {
        const a: number = 1;
        const b: typeof a = 2; // OK
        const c: this.x = 3; // No :(
        const d: this['x'] = 3; // OK
        const e: typeof A.y = 4 // OK
    }
}

@ NN ---これには、いつでもインデックス付きの型を使用できます。

this['x']

@cameron-martin動作しません。 遊び場

@ tycho01新しい型の推論と条件文は素晴らしいですが、関数のオーバーロードでは機能しないことも非常に厄介です。 与えられた理由は、可能なものから関数型を解決するために、このtypeofのようなものが必要だったからです。

@NNはconst d: this['x'] = 3;を使用するだけです

いいね ：）

@NN---または使用

class A {
    x: number;
    static y: number;
    f() {
        const self = this;
        const a: number = 1;
        const b: typeof a = 2; // OK
        const c: typeof self.x = 3; // OK
        const d: typeof self['x'] = 3; // OK
        const e: typeof A.y = 4 // OK
    }
}

@tsofist地元で働いていることは知っていますが、これは醜いです。
これは、暗黙のキャプチャでラムダを使用する代わりに、「function（）{}」コールバックの「this」を手動で保存するのと同じです。

@NN

この醜い。

うん、これは単なるオプションです:)

特定の引数のセットを検証する場合は、特定の他のエイリアスと一緒にReturnTypeOf<T>を記述できるため、条件付きタイプではこれがほとんど無関係になります。 彼らは過負荷の解決を行うことはできませんが、この機能はそのユースケースのためだけに複雑にする価値があるとは思いません。

@RyanCavanaugh私はあなたがReturnType<T>を意味すると思いますか？

残念なことに@RyanCavanaugh-過負荷の解決は私が本当に必要としていたものです。 条件付き/推論タイプへの過負荷解決の追加を追跡する別の問題はありますか？

あなたはそれを書くことができるはずです：

type Return1<A1, T extends (a: A1) => any> = T extends (a: A1) => infer R ? R : any;
type Return2<A1, A2, T extends (a: A1, a: A2) => any> = T extends (a: A1, a: A2) => infer R ? R : any;

declare function something(a: number): number;
declare function something(a: string): string;
declare function something(a: number, b: string): boolean;

type A = Return1<number, something>; // number
type B = Return1<string, something>; // string
type C = Return2<number, string, something>; // boolean

ただし、テストは行っていません。引数の数ごとに個別のヘルパーが必要になります。

@ForbesLindesay ： somethingは現在、式レベルの変数です。たとえば、ここでtypeofを参照して（またはインターフェイスとして宣言して）修正します。 私は実際には、適切なリターンタイプを生成するように管理していません（ 2.8.0-dev.20180318 ）。

@ForbesLindesay残念ながら、それがうまくいくとは思いません。 推論メカニズムは、_last_メソッドのオーバーロードを選択します。

type Funcs = ((p1: string, p2: string) => void) & ((p1: number) => void);

type FuncPromise1<T> = T extends (p1: infer P1) => void ? (p1: P1) => Promise<[P1]> : never;
type FuncPromise2<T> = T extends (p1: infer P1, p2: infer P2) => void ? (p1: P1, p2: P2) => Promise<[P1, P2]> : never;

let foo: FuncPromise1<Funcs> & FuncPromise2<Funcs>;

ただし、推論メカニズムはタプルユニオンを処理できます。

type Tuples = [string, string] | [number];

type TuplePromise1<T> = T extends [infer P1] ?  (p1: P1) => Promise<[P1]> : never;
type TuplePromise2<T> = T extends [infer P1, infer P2] ? (p1: P1, p2: P2) => Promise<[P1, P2]> : never;

let foo: TuplePromise1<Tuples> & TuplePromise2<Tuples>;

オーバーロード->オブジェクト、関数->オブジェクト、アンラップを許可するものが必要な場合があります。 そこで型マッピングと推論を実行してから、関数にラップバックしてオーバーロードします。

@MeirionHughes ：

オーバーロード->オブジェクト、関数->オブジェクト、アンラップを許可するものが必要な場合があります。 そこで型マッピングと推論を実行してから、関数にラップバックしてオーバーロードします。

(a: number, b?: string) => boolean -> { a: number, b?: string }のように？ そのようなパラメータ名はまだ取得できませんが、オブジェクトタイプを使用して順序付けを行うことができないため、概念的には、RESTパラメータ（ (a: number, ...b: string[]) => boolean ）ではこれが難しくなります。

順序はおそらく名前よりも重要であり、パラメーターとタプルの間で変換できます。 スプレッド/オプションは、それでも少し複雑になる可能性があります。

これにより、過負荷の抽出に関する問題が軽減されます。 オーバーロードは((a: number) => 123) & ((s: string) => 'hi')のような関数型の交差である必要があるため、問題は交差型を（たとえばタプル型に）「アンラップ」する方法です。現時点では、それはありません。

このパスは、オーバーロードのユースケースに対応しているものの、ジェネリックとは言えないため、満足のいくものではありませんが、そうです。 交差点のアンラッピングは、いずれにしてもまだギャップでした。

この号は現在クローズされていますが、まだ不足している部品についての新しい提案はまだありますか？ 引数に応じて戻り型を処理する方法のように？

この号は現在クローズされていますが、まだ不足している部品についての新しい提案はまだありますか？

私が知っているものはありません。

引数に応じて戻り型を処理する方法のように？

コールタイプの追跡に問題があるとは思わないでください。

タイプレベルの関数適用を追加するというアイデアの予備的なサポートはありますか？ そのための提案を書くことができました。 構文的には、それが最も簡単な方法だと思います。

type MyType<A> = {
    foo: A
}

type Wrap = {
    <T>(maybe: MyType<T>): MyType<T>;
    (maybe: any): MyType<any>;
}

type Naive = ReturnType<Wrap>; // Naive = { foo: any }
type Proposed1 = Wrap(maybe: number); // Proposed1 = { foo: number }
type Proposed2 = Wrap(maybe: MyType<number>); // Proposed2 = { foo: number }
type Proposed3 = (<T>(maybe: T) => MyType<T>)(maybe: number) // Proposed3 = { foo: number }

エッジケース：

const foo = <T>(a: T) => T:

type Edge1 = (typeof foo)(a: number) // Probably trivial?

type Foo = {
    <T>(a: string): T
}

type Edge2 = Foo<number>(a: string) // Should this be allowed? Probably not, because:

type Bar<A> = {
    (a: string): A
}

type Edge3 = Bar<number>(a: string) // Things are getting strange

interface Baz<A> {
    <T>(a: T): T | A
}

type Edge4 = Baz<number>(a: string) // What is this?

タイプレベルの関数適用を追加するというアイデアの予備的なサポートはありますか？ そのための提案を書くことができました。 構文的には、それが最も簡単な方法だと思います。

現時点ではありません。 オーバーロードの解決を高次の型の空間に入れたくはありません。 このプロセスはかなり複雑で、型パラメーターを推測するための複数のパスや、コンテキストに応じて型引数などが含まれます。これを高次で行うことは、最初は多くの作業であり、次に、で処理する準備ができていないパフォーマンスの課題を引き起こします。当分の間。

@mhegazyは、＃24897の最近の作業を考えると、これに対するチームのスタンスをまったく変えましたか？

その解決策を$Callタイプに減らすことができる問題はかなりあるようです。また、 $Callタイプは、より種類の多いタイプをエミュレートする比較的簡単な方法への扉を開きます。 たとえば、 https：//gist.github.com/hallettj/0fde5bd4c3ce5a5f6d50db6236aaa39eを参照してください（ $PropertyTypeと$ObjMapの使用を$Callに置き換えます）。 編集：追加の例： https ：//github.com/facebook/flow/issues/30#issuecomment -346674472

そのような機能は、間違いなく、多くの問題に対する合理的な共通の解決策を見つけたTypeScriptの実績と一致しているでしょう。

特定の引数のセットを検証する場合は、特定の他のエイリアスと一緒にReturnTypeOf<T>を記述できるため、条件付きタイプではこれがほとんど無関係になります。 彼らは過負荷の解決を行うことはできませんが、この機能はそのユースケースのためだけに複雑にする価値があるとは思いません。

@RyanCavanaugh @mhegazy

条件付き型を使用して物事を行うことが可能であることに同意します。 User.avatarをUser extends { avatar: infer T } ? T : neverに書き直しても、コンパイラにそれほど複雑さはもたらされないと思いますか？ たとえば、次のように書くことができます

export type Avatar = User extends { avatar: infer T } ? T : never;

なので

export type Avatar = User.avatar;

読みやすさを向上させるため。

完全な例

いくつかのデータをロードして変換し、最終的に次のような関数findUserを作成するとします。

export function findUser() {
  return {
    username: 'johndoe',
    avatar: {
      lg: '1.jpg',
      s: '2.jpg'
    },
    repos: [
      {
        name: 'ts-demo',
        stats: {
          stars: 42,
          forks: 4
        },
        pull_requests: [
          { date: '2019-08-19', tags: ['bug', 'agreed-to-cla'] },
          { date: '2019-08-10', tags: ['bug', 'includes-tests'] },
          { date: '2019-08-07', tags: ['feature'] }
        ]
      }
    ]
  };
}

マップされた型からの推論のおかげで、次のように関数から型を抽出できます。

export type User = ReturnType<typeof findUser>;
export type Avatar = User extends { avatar: infer T } ? T : never;

提案：これは同じことを評価する必要があります

export type Avatar = User.avatar;

さらに、 User.avatarのタイプがneverであってはならないと断言することもできます。

その他の例

export type Repositories = User extends { repos: infer T } ? T : never;
export type Repository = User extends { repos: (infer T)[] } ? T : never;
export type RepositoryStats = Repository extends { stats: infer T } ? T : never;
export type PullRequests = Repository extends { pull_requests: (infer T)[] } ? T : never;
export type PullRequest = Repository extends { pull_requests: (infer T)[] } ? T : never;
export type Tags = PullRequest extends { tags: infer T } ? T : never;
export type Tag = PullRequest extends { tags: (infer T)[] } ? T : never;

export type Repositories = User.repos;
export type Repository = User.repos[];
export type RepositoryStats = User.repos[].stats;
export type PullRequests = User.repos[].pull_requests;
export type PullRequest = User.repos[].pull_requests[];
export type Tags = User.repos[].pull_requests[].tags;
export type Tag = User.repos[].pull_requests[].tags[];

ネストされたプロパティを一度にマッピングする場合、何が起こっているのかが明確ではありません

export type Tag2 = User extends { repos: { pull_requests: { tags: (infer T)[] }[] }[] } ? T : never;

これはそれを大いに明らかにするでしょう

export type Tag = User.repos[].pull_requests[].tags[];

コーナーケース

export class Hello {
  static world = 'world';
  world = 42;
}

export type ThisWillBeANumber = Hello extends { world: infer T } ? T : never;
export type ThisWillBeANumber = Hello.world;

export type ThisWillBeAString = (typeof Hello) extends { world: infer T } ? T : never;
export type ThisWillBeAString = (typeof Hello).world;

@lukaselmerあなたが欲しいだけのようです

export type Avatar = User["avatar"];

今日は機能します

@lukaselmerあなたが欲しいだけのようです

export type Avatar = User["avatar"];

今日は機能します

それがまさに私が探していたものです。 ドキュメントで検索していましたが、見つかりませんでした。 ありがとう！

これはハンドブックの一部ですか、それともこれがどのように機能するかについての公式ドキュメントはありますか？ 私はそれを使用する方法にかなり精通していますが、私が人々をドキュメントに誘導しようとすると、私が見つけることができるのはタイプの警備員だけです、それは本当に完全に異なります

そのため、この提案は2015年から跳ね返り、当初の目標の1つは、インターフェイスの単一のプロパティのタイプを何らかの方法で取得することであったことに気付きました。

interface a {
 foo: bar;
 /* more types */
}

const example = (fooNeeded: [magic] a.foo ) => {};

これは5年後もまだ不可能だと思いますか？

@MFryあなたはこの構文を探していると思います： a['foo']

これに対する解決策がまだあるかどうか知っていますか？

私はこのようなものを手に入れようとしています：

declare function something<A, B>(): void;

type Payload = string;

const hello = something<{}, Payload>();

declare function doThing<T extends ReturnType<typeof something>>(arg: T): { payload: unknown };

doThing(hello).payload === 123; // this should validate to a string aka type Payload

https://www.typescriptlang.org/play/index.html?ts=4.0.0-dev.20200512#code/CYUwxgNghgTiAEAzArgOzAFwJYHtXwGccBbEDACy1QHMAeAQQBp4AhAPgAoBKALngDccWYAG4AUGIwBPAA4IAClCkQcUYPAC8hDDCrVxYsHgIZ45EBBWbCJMpRq0A3gF9mi5auCcuB0JFgIKOjYePDAOAAq9nQR8CAAHhggqMAE8ABKZMgwqBGyILTScjiINqQUemycsNR8EbzwjvAySipqfGgA1qg4AO74zr6R0RzmljhcAHQtHmqaGloAjABMAMwi8AD0m -AVaQTkOMgQ6vxQEMJQSbs48FDaujR3nfdFCq2eYkA

こんにちは@maraisr私はあなたが何を達成しようとしているのか100％確信が持てません。 あなたの例では、 somethingは2つのタイプを取りますが、それらを使用しません。 helloは、常にvoidになる何かの戻り値です。 したがって、 doThingは、どの時点でもタイプstringを認識しません。

たぶん、以下のようなものがあなたが望むものですか？

declare function something<ReturnType>(): ReturnType;

type Payload = string;

const hello = () => something<Payload>();

declare function doThing<F extends () => any>(f: F): { payload: ReturnType<F> };

doThing(hello).payload === 'a string';

そうそう、それについてはごめんなさい。 迅速な対応ありがとうございます!! ：100： @acutmore

voidは、その関数のreturntypeが無関係であることを示すためだけのものでした。 これらの2つの型は他のジェネリック型に転送され、最終的に引数で使用されます。

何かのようなもの：

declare function something<A, B>(a: MyComplexGeneric<A>, b: B[]): { somethingA: number, somethingB: number };

// Those 2 generics influence the return object so they do get used as such. And the 2 arguments are roughly that. Its an object and an array, more-or-less. 

私のdoThing関数は、最初の（ A ）ジェネリックが何であるかを実際には気にしませんが、2番目（ B ）が何であるかは気にします。

私自身のユースケースのsomethingは、 doThingによって読み取られる副作用を実行することを確認してください。

したがって、関数のReturnTypeを単純に取得することはできません。作成された関数のジェネリックをなんとかして吸い出す必要があります。

このクエリがこの問題の範囲を超えていると思われる場合は、StackOverflowで私の旅を続けてください！

@maraisr追加情報をありがとう。

doThingで元のBタイプをsomethingから取得できるようにする場合は、何らかの方法でhelloに渡す必要があります。 TypeScriptはhelloのみを調べており、助けがなければ、それがsomethingのリターンタイプであることがわかりません。

これは、これを実行できる1つの方法です。

/** Create a type that can store some extra type information **/
interface SomethingResult<T> {
    __$$__: T;
    somethingA: number;
    somethingB: number;
}

declare function something<A, B>(): SomethingResult<B>;

type Payload = string;

const hello = something<{}, Payload>();

declare function doThing<Result extends SomethingResult<any>>(arg: Result): { payload: Result['__$$__'] };

doThing(hello).payload === 1123; // error because `payload` is of type string

interface User {
  avatar: string;
}

interface UserData {
  someAvatar: User['avatar'];
}

@RyanCavanaughなぜこれが閉鎖されているのですか？ 条件付きタイプは、これや他の多くのユースケースを解決しません。これをマージすると、非常に多くのことが可能になります。

私は、任意のメソッド呼び出しを「ポイントフリー」バージョンに変換できる関数に取り組んでいます（例： [].map(() => n > 5)はmap(() => n > 5)([])に変換され、不足しているのは条件型とinferだけです。 unknownとして出力されます。

関数を「呼び出し」て型（ typeof myFunc(() => Either<string,number>) ）を取得できれば、この機能（現在は不可能）を使用して、他の多くのこと（HKTなど）をはるかに簡単にすることができます。 。）

$Callを関数（フローのように）にできるようにするための複雑さは非常に高いですか？ typescriptはすでにそれを自動的に行っているような気がします。

@nythroxこれがもたらす可能性のある構文上の混乱が、あるタイプに到達するために必要な場合よりも重要であるとは感じていません。 呼び出し式を解決する特定のケースは、他の場所で追跡されます。 OPでの「あらゆる表現を許可する」という提案は、この言語に適しているとは思われません。

@RyanCavanaughああ、わかりました。 返信ありがとうございます。関数呼び出しの解決を追跡している問題を知っていますか？

少し調べてみましたが、関数呼び出しユーティリティタイプの問題は見つかりませんでした。 私が見つけたものへの唯一の参照は、この問題にリンクしている＃20352にありました。

呼び出し式を解決する特定のケースは、他の場所で追跡されます

@RyanCavanaughマインドは他の場所にリンクしていますか？ 🙂

@tjjfvi ＃37181は、より具体的には、入力に基づいて関数を解決することに関するものです。 あなたが探しているものかもしれません。

@acutmoreこれは私が探していたものにいくらか沿っていますが、フロー風の$Callユーティリティ、またはそのような実装を可能にする他の構文について具体的に話していました。 アプローチは奇妙なことを示唆しましたが、リンクに感謝します。