+1、これはTypeScriptの関数型プログラミングに非常に役立ちます！ これは、オプションの引数またはREST引数でどのように機能しますか？ より具体的には、 compose関数は、REST引数またはオプションの引数を持つ関数で使用できますか？

いい視点ね。 タプルは単なるオブジェクトであり、追加のメンバーを許可するため、許可される最小のタプルタイプをoptional-param関数に割り当てることができると思います。 しかし、それは理想的ではありません。 compose例を理解できるかどうかを確認してから、提案を更新します。

実際には、共用体型の方がおそらくうまくいくでしょう。 何かのようなもの

function f(a: string, b? number, ...c: boolean[]): number;
function id<T>(t: T): T;
let g = compose(f, id): (...ts: ([string] | [string, number] | [string, number, boolean[]]) => number

g("foo"); // ok
g("foo", 12); // ok
g("foo", 12, [true, false, true]); // ok

ただし、これでも残りのパラメーターは壊れます。

@ahejlsberg 、タプルの種類がどのように機能するかについていくつかのアイデアがあったと思います。

だから：+1：これについて。 情報については、これは＃3870に関連しています（そして満たすでしょう）。 TypeScriptで作成タイプAPIを実装しようとしましたが、この提案に記載されている制限のいくつかを回避する必要があります。 これは確かにそれらの問題のいくつかを解決するでしょう！

特にcomposeのようなものでは、そのようなタプルタイプを永続化するのではなく、「マージ」したい場合があるようです。 例えば：

function compose<T, ...U>(base: T, ...mixins: ...U): T&U {
    /* mixin magic */
}

また、多くの例では、プリミティブを使用しています。 特に競合がある場合、より複雑な機能がどのように機能すると思いますか？

残念ながら、タプルの種類の唯一の合成演算子は[T,...U]であるため、この提案はそのままでは＃3870または型合成に対応していません。 これをT + ...U （型に何が起こるかをよりよく示します）と書くこともできますが、＃3870と型構成ライブラリにはT & ...Uが必要です。 私はそれが可能かもしれないと思うが、私は最初の＃3870から@JsonFreemanさんと@jbondcの考えを理解する必要があります。 それがどのように機能するかを理解できれば、提案を拡大します。

注：同等の値拡散構文のように見えるため、構文[...T, ...U]ことにしましたが、 T + ...Uは、型で何が起こっているかをよりよく示しています。 最終的に両方になる場合は、 +と&が使用する演算子である可能性があります。

ビッグ：+1：これで！

+1すごい！ それはそのようなものをはるかに表現力豊かで軽量に表現することを可能にするでしょう。

＃3870の私のポイントはここで問題のようです。 具体的には、可変個引数型パラメーターの型引数を推測することについて心配しています。

型引数の推論はかなり複雑なプロセスであり、時間の経過とともに微妙に変化しました。 型型引数を推測するために引数がパラメーターと照合される場合、候補が推測される順序や、（特定の型パラメーターに対して）推測される候補の数についての保証はありません。 ユーザーに表示される結果は（ほとんどの場合）これらの詳細を公開しないため、これは一般的に問題ではありませんでした。 しかし、推論結果からタプル型を作成すると、推論の順序と数の両方が明らかになります。 これらの詳細は、観察可能であることを意図したものではありません。

これはどれくらい深刻ですか？ 推論がどれだけ正確に機能するかによると思います。 次の結果は何ですか：

function f<...T>(x: ...T, y: ...T): ...T { }
f(['hello', 0, true], [[], 'hello', { }]); // what is the type returned by f?

@jbondc 、 -は良い考えのようです。 新しいタイプの演算子を1つずつ導入する必要があると思うので、ここではそれを念頭に置いていますが、ここでは説明しません。 &と+両方が新しい型を作成しますが、 &は交差型を作成し、 +は新しいタプル型を作成します（これが構文[T,...U]を好む理由です） T + ...U [T,...U]代わりに[T,U]すでに型に対してこれを行っているため）。

@JsonFreeman lは、種類パラメータを繰り返して2つのことのいずれかを実行しても問題ないと思います。

1. タイプを結合する： f(['hello', 1], [1, false]): [string | number, number | boolean]
2. 特に型引数の推論が複雑であることが判明した場合は、繰り返されるタプルの種類パラメーターの推論を禁止します。 このようなもの：

f(['hello', 1], [1, false]) // error, type arguments required
f<[string, number]>(['hello', 1], [1, false]) // error, 'number' is not assignable to 'string'
f<[string | number, number | boolean]>(['hello', 1], [1, false]); // ok

実際のライブラリ（ @Igorbekがリンクされているリアクティブ拡張など）には通常、タプルの種類のパラメーターが1つしかないため、（1）も（2）も特に使用できなくても、実際のコードに大きな影響を与えることはないはずです。

上記の例では、 curry最も難しい推論することである-あなたはスキップする必要がf: (...args:[...T,...U]) => V推測し、 ...ts:...T 、その後、戻って設定...U何にfのパラメータから...Tを消費した後に残った。

私はこれ（sandersn / TypeScript @ 1d5725d）のプロトタイピングを開始しましたが、まだそれほど進んでいません。 それがうまくいくかどうか何か考えはありますか？

私は、セマンティクスが明確でないもの（同じ拡散型パラメーターへの繰り返しの推論など）を禁止する側で誤りを犯します。 それは上記の私の懸念も和らげます。

カレーをタイプするのに良いメカニズムが思いつかない。 ご指摘のとおり、 ...T引数を使用するには、最初の関数のパラメーターリストをスキップして、残っているものを確認する必要があります。 リストの最後ではない場合、拡散型パラメーターへの推論を延期するためのポリシーが必要になります。 乱雑になる可能性があります。

そうは言っても、これは試してみる価値があると思います。 この機能に対する需要は高いです。

同じコンテキストで発生する複数のタプルの種類をスキップする必要があると思います（たとえば、 (...T,string,...U) => Vようなトップレベル、または[...T,...U,...T]ように連結されたもの）。 次に、スキップされた種類に対して複数のパスを作成して、すでに推測された種類を削除し、まだあいまいな種類を再スキップすることができます。 推論に使用できる単一の種類がない場合は、停止してエラーを返します。

だから、ええ。 複雑。

同様の問題からインスピレーションを引き出すことができるかもしれません。 これは、実際には、和集合または共通部分を推測する問題にいくぶん似ています。 function f<T>(x: T | string[])ように、推論コンテキストのメンバーである型パラメーターを含む共用体型を推論する場合、Tを推論するかどうかはわかりません。共用体型の意図された表現は次のようになっている可能性があります。 string[] 。 したがって、typescriptは最初に他のすべての構成要素を推論し、次に推論が行われなかった場合はTを推論します。

交差点の場合、引数のタイプを異なる交差点の構成要素に分割しなければならない可能性があるため、さらに困難になります。 Typescriptは交差型をまったく推測しません。

タプルがシーケンスの最後のタイプである場合にのみ、タプルの拡散を許可した場合はどうなりますか？ したがって、 [string, ...T]は許可されますが、 [...T, string]は許可されませんか？

私が正しく理解していれば、これは実際にTypeScriptのミックスインストーリーを解決するでしょう。 私はこの理解で正しいですか？

多分。 例を挙げていただけますか？ 私はミックスインパターンに堪能ではありません。

可変個引数の種類変数の構文は... Tです。ここで、Tは、慣例により単一の大文字である識別子、またはTの後にPascalCase識別子が続きます。

タイプパラメータ識別子の場合は開発者に任せることができますか？

@ aleksey-bykov + 1。 そうすべきではない理由がわかりません。

Haskellのバックグラウンドを持つ開発者はそれをいただければ幸いです。

申し訳ありませんが、その文はあいまいに解析される可能性があります。 私は「または」を厳密に解析することを意味しました：「慣例により（単一の大文字|| Tの後にPascalCase識別子が続く）」。 私は識別子の大文字と小文字を制限することを提案しているのではなく、慣例を指摘しているだけです。

しかし、その価値については、_I_はHaskellのバックグラウンドを持っており、私が書いている言語の慣習を破るのは好きではありません。

脱線してすみません。 私の最後の不思議な質問（あなたが私に尋ねても構わないのなら）は、壊れるかもしれないTypeScriptの「慣習」とは何ですか、そして誰が心配していますか？

@sandersn

T & ...U T & U & V & ...意味すると仮定すると、これはcheckと入力する必要があります（これは直感的な動作です）。

function assign<T, U, ...V>(obj: T, src: U, ...srcs: ...V): T & U & ...V {
  if (arguments.length < 2) return <T & U & ...V> obj

  for (const key of Object.keys(src)) {
    (<any> obj)[key] = (<any> src)[key]
  }

  if (arguments.length === 2) return <U> obj
  return mixin<T, ...V>(obj, ...srcs)
}

または定義ファイル内：

interface Object {
    assign<T, U, ...V>(host: T, arg: U, ...args: ...V): T & U & ...V
}

@ aleksey-bykov私が話している規則は、型パラメーター識別子の場合です。 誰が心配ですか？ これまでに見たことのない新しいTypescriptコードを読まなければならない人々-慣習は、新しい読者が新しいコードをより速く理解するのに役立ちます。

@sandersn @ aleksey-bykovが印象に残ったのは、以下は_構文的に_無効になるということでした。

function assign<a, b, ...cs>(x: a, y: b, ...zs: ...cs): a & b & ...cs;

@isiahmeadows &および|種類に対する操作は、この提案ではカバーされていませんが、未解決の質問/将来の作業に追加する必要があります。 現在、提案されている演算子は連結のみです： [THead, ...TTail] 。

1つの違いは、連結によってタプル型が生成されるのに対し、 &と|はそれぞれ共通部分と共用体型を生成することです。

@sandersn TypeScriptでの私のassign例は、それで変更するのは簡単です。

それでも：

1. 交差は連結に似ていますが、リストを連結するというよりは辞書を連結するようなものです。 可変個引数タイプは、既存の機械の上に実装される場合があります。
2. ユニオンは、共通部分のみを保持していることを除けば、交差点のようなものです。 繰り返しになりますが、可変個引数タイプは既存の機械の上に実装される可能性があります。

@isiahmeadows交差点は、一般に辞書の連結ではありません。 これは、オブジェクトタイプの共通部分にのみ当てはまりますが、たとえばユニオンの共通部分には当てはまりません。 ユニオンは、オブジェクトに共通するプロパティを取得することと同じではありません。 この2つは、それらに存在する一連の値によってよりよく特徴付けられます。

@sandersn型引数の推論と可変個引数の種類について少し混乱しています。 ここで何を推測する必要がありますか？

function foo<...T>(...rest: ...T): ...T { }
foo('str', 0, [0]);

結果は[string, number, number[]]ですか？ つまり、候補者を左から右の順序で追加する型引数の推論に依存する必要がありますが、これは簡単な仮定ではありません。 また、型システムが推論候補のリストをユーザーに表示するのはこれが初めてです。

これは実験的/初期の提案ですが、RESTパラメーターの...T構文について説明することはできます。 私の観点からは、それは実際には機能しません。
したがって、提案される構文は次のとおりです。

declare function f<...T>(...a: ...T);

RESTパラメーターの既存の構文と比較してみましょう。

declare function f(...a: number[]);

したがって、REST引数をキャッチするaパラメーターのタイプはnumber[]であるため、これが配列であることが明確に理解できます。 類推すると、提案の...Tも配列を表していると推測できます。 しかし、それはあまり明白ではありません。
次に、より制限的なRESTパラメーターを定義できるとしましょう。

declare function f(...a: [number, string]);
// same as
declare function f(c: number, d: string); // or very close to

したがって、今でも、 aタイプがタプル（配列）であることがわかります。

私の提案は、 ...T概念をより一貫した方法で処理して、「タイプの抽象的な順序付きリスト」として表すことです。 そして、スプレッド演算子を使用するのと同じ方法で使用します。

var a: [number, string] = [1, "1"];
var b = [true, ...a]; // this must be [boolean, number, string], but it doesn't work :)

したがって、変数の場合の...aは、 1, "1"すぎません。

...T概念でRESTパラメーターを定義するための私の構文：

declare function f<...T>(...a: [...T]);
declare function g<H, ...T>(head: H, ...tail: [...T]): [H, ...T];

私にとって、それははるかに理にかなっています。

@Igorbek declare function f<...T>(...a: ...T);すでにそのように機能していると仮定して実行しています。 しかし、 declare function f(...a: [number, string]);があまり使われていないようです。

より明確にするために。

残りのパラメーターに対して最初に提案された構文：

function func<...T>(...a: ...T)

私がこれを行うことができれば

function g<...T>(...a: ...T): [number, ...T] { ... }

その後、私はこれを行うことができるようになります：

function f<...T>(...a: ...T): [...T] { return a; }

したがって、 aのタイプは[...T] （これを返します）が、署名では...Tとして定義しました。
...Tと[...T]は同じであると言えますが、変数の場合は機能しません。
変数の場合：

var a = [1, 2];
[a] === [[1,2]];
[...a] === [1, 2];
f(...a) === f(1, 2)
...a === 1, 2 // virtually

標準のRESTパラメーターに同じものを適用する場合

function f(...a: number[]): number[] { return a; }

aタイプは、署名で定義されたものと同じnumber[] （リターンタイプ別）です。

@isiahmeadowsはい、 function f(...a: [number, string])は機能しません。 私は、RESTパラメーターをどのように扱うことができるかについての考えを開発しました。

だから、さらに進んでください。 型パラメーターを明示的に定義するために、次の構文が提案されました。

function f<...T, ...U>()
f<[number, string], [boolean, number]>();

に向けて：

f<...[number, string], ...[boolean, number]>();

したがって、これも機能する可能性があります。

function g<T1, T2, T3>()

g<A, B, C>();
// same as
g<...[A, B, C]>();
g<...[A], ...[B, C]>(); 
g<...[A], B, C, ...[]>();

@JsonFreemanは、私のプロトタイプがどのように機能するかです、はい。 しかし、私は型推論アルゴリズムに精通していないため、なぜそれが機能するのかを理解できません。 言い換えれば、問題は、左から右への推論が_些細な_仮定であるかどうかではなく、正しい仮定であるかどうかです。 アイデンティティの場合、答えは「はい」ですが、答えが「いいえ」の場合を作成できるかどうかはわかりません。

また、公開された型推論候補のセットの例を実行できますか？ 私が言ったように、私は推論アルゴリズムの働きをよく理解していないので、例はあなたが何を意味するのかを理解するのに役立ちます。

そしてさらに良い：

function<...T>(...a: T): T;
// same as
function<...T>(...a: [...T]): T;

残りのタイプパラメータを示すために、タイプ識別子の前に[]を付けることをお勧めします。

function fn<R, []T>(...a:[]T): R;

...Tより1文字短く、（私の意見では）視覚的なノイズが少なくなります。

@ aleksey-bykov私は実際にはそれについて反対意見です。 これは既存のRESTパラメーター構文に適合しないため、一見しただけでもわかりにくいと思います。

残りの配列パラメータータイプとしての[...T] / Tは、私にとってはるかに優れているようです。 もう一度、配列とそのsprad演算子と比較してください。

| 配列| タイプ（提案から）| タイプ（私の更新）|
| --- | --- | --- |
| var x = [1,2] | いいえ| T = [T1, T2] |
| [0, ...x] === [0,1,2] | [T0, ...T] === [T0, T1, T2] | [T0, ...T] === [T0, T1, T2] |
| f(x) === f([1, 2]) | いいえ| f<T>() === f<[T1, T2]>() |
| f(...x) === f(1, 2) | f<...T>() === f<[T, T2]> ？ | f<...T>() === f<T1, T2> |
| f(0, ...x) === f(1, 2) | f<T0, ...T>() === f<T0, [T, T2]> ？ | f<T0, ...T>() === f<T0, T1, T2> |

提案から

function g<...T>(...x: ...T) {
 // being called as g(1, "a");
  var a: ...T; // [number, string] ?
  var b: [number, ...T]; // [number, number, string]
  var c: [...T]; // [number, string] - same as a ? so [...T] is same as ...T - weird
}

私の更新から

function g<...T>(...x: T) {
 // being called as g(1, "a");
  var a: T; // [number, string]
  var b: [number, ...T]; // [number, number, string]
  var c: [...T]; // [number, string]
}

アップデートはIMOの方が見栄えがします。 タイプを表すリストは非常にいいように聞こえますが、タイプされたLispでさえそれほど遠くには行きません（同像性タイプ、誰か？：smile :)。

私は純粋さの魅力を感じますが、実用的な側面も見ています。 リストは、それ自体で比較的簡単に実装することもできますが、他の言語には適合しません。 これは、Java（言語）でモナドを実装したり、Cでラムダを実装したりする多くの試みとほとんど同じです。それらは常に信じられないほど醜くハックなものになります。

@sandersn候補者のリストを公開することで、私が何を意味するのかを説明しようと試みることができます。 型引数の推論により、各型パラメーターの候補のリストが生成されます。 次に、いずれかの候補が他のすべてのスーパータイプであるかどうかを確認し、そうである場合は、その候補が勝者です。 したがって、次の例では：

function foo<T>(a: T, b: T): T {}
foo(["hi", 0], ["", ""]);

引数が入力され、各パラメーターに推測されます。 (string | number)[]とstring[] 2つの候補が生成されます。 しかし、最初のものは2番目のスーパータイプであるため、勝ちます。 その結果、ユーザーはstring[]が写真に写っていることに気付くことTには1つの推論があり、他のすべての候補は表示されません。 これは、ユーザーには見えないものが2つあることを意味します。つまり、候補者の順序と候補者の多様性です。

...T示されるタプル内の要素のリストとして候補リストに依存している場合、多重度に関する問題があります。

function foo<...T>(...rest: ...T): ...T
foo(0, 1);

私が理解しているように、あなたの提案の意図を考えれば、Tについて[number, number]を推測したいと思うでしょう。 ただし、 https：//github.com/Microsoft/TypeScript/blob/master/src/compiler/checker.ts#L6256に含まれるチェックインラインがあるため、 number候補は1回だけ追加され、 Tは[number]として推測されます。 これは私が話していた多元性の問題です。

順番は左から右です。 ただし、複数のパスがあり、コンテキストで型指定される関数式が引数に含まれている場合、引数は再処理されます。 コンテキストで型指定された関数式を含む引数がn個ある場合、引数はn +1回渡されます。 例としては、Array.prototype.reduceがあります。ここでは、initialValueパラメーターが右側にあるにもかかわらず、コールバックの前に効果的に型指定され、推測されます。 したがって、次のようなものが提案の問題になる可能性があります。

function foo<...T>(...rest: ...T): ...T
foo(x => x, 0);

直感的には、Tは[(x: any) => any, number]である必要がありますが、候補が追加される順序に依存する場合は、 [number, (x: any) => any]ます。 これは、型引数の推論は一般に左から右に行われるが、コンテキスト型付けの対象となる関数は最後まで延期されるためです。

私が説明した多重度と順序の問題はどちらも、候補者リストを表面化する例です。 @ahejlsbergは確かにこれについても尋ねるのに良い人であり、実際彼は私が言ったことを説明、確認、または反証するのを手伝うことができます。

@JsonFreemanなぜそれが問題になると思うのですか？
これは、残りのファクチュアル引数ごとに追加のジェネリック型を仮想的に導入し、固定パラメーター長の関数に対して推論することで実装できます。
例えば、

function foo<...T>(...rest: T) { ... }
foo(x => x, 0);
// to infer, the following function is used
function foo2<T0, T1>(rest0: T0, rest1: T1) { ... }
foo2(x => x, 0);
// inferred as
foo2<(x: any) => any, number>
// T0 = (x: any) => any
// T1 = number
// T = [T0, T1] = [(x: any) => any, number]

ところで、 x => xが{ <T>(x: T): T; }型であると推測できますか？

@Igorbek製造タイプのパラメーターについてのあなたの提案（少なくともそれがどのように実装されているかに関係なく、直感として）はそれを行う正しい方法だと思います。 Tのタイプのシーケンスを推測できます。ここで、シーケンス内の各要素にはインデックスと候補のリストがあります（これはあなたが述べたことを実装する別の方法です）。

しかし、私の言いたいことは、推論候補リストを推論されたタプルとして再利用した場合、これが自然に起こることではないと思います。 正しいことを実現するには、明示的なメカニズムが必要になります。

{ <T>(x: T): T; }についてのあなたのポイントについてx => foo(x)ようなものをタイプすることにうまく一般化されません。 foo過負荷解決を行うには、 xのタイプを知っている必要があります。

タイプチェッカー推論規則との戦いからの小さな一歩。
構文についてのコメント/提案があります。 一貫しているが相互に排他的な2つのオプションがあると思います。

1.正式なREST型引数

このフォームを選択した場合：

type F<...Args> = (...args:...Args) => ...Args

それなら私達はそれを次のように使うべきです

var a:  F // a: () => []
var b:  F<number> // b: (arg: number) => [number]
var c:  F<number, string> // c: (arg1: number, arg2: string) => [number, string]
...

したがって、それは真のレストフォーマルタイプになります。 これらは、正式なタイプパラメータセクションの最後の位置でのみ使用する必要があります。

2.タプル型のREST引数

(...args:[string, number]) => boolean    IS EQUIVALENT TO   (s: string, n: number) => boolean

この場合、フォーマルタイプのパラメータセクションには常に固定数のスロットがあります。

function f<T>(...args: T): T {
    return args;
}

いずれかの条件が満たされた場合、Tはタプル型である必要があると推測します。

1. Tは、（... args：T）=> TのようなRESTパラメーターに使用されます
2. Tは、[... T]や[number、... T、string]などのスプレッド構成で使用されます。

したがって、正式な型パラメータセクションで省略記号を使用する必要はありません（型チェッカーがなくても_構文的に_推測できます）

この場合、私たちはまた書くことができます

function f<T>(...args: [...T]): [...T] {
    return args;
}

しかし、それは冗長です。

個人的には、後者がTypeScriptに実装されることを望んでいます。 @ JsonFreeman 、@ sandersn？

@Artazor表現要約すると、2つのアプローチが必ずしも同等であるとは思いません。 2つ目は、REST型パラメーターをタプル型内に拡散する機能を備えていますが、1つ目はそうではないようです。

ジェネリック型の参照の場合、REST型パラメーターをどこで構文的にどのように使用するかを決定するだけだと思います。 これは、型シーケンス（タプル、シグニチャ、ジェネリック型参照）をとるすべての型コンストラクターに対して決定する必要があります。

一般的な署名の場合、型引数の推論のために、より複雑になります。 次の場合はどうなりますか。

function callback(s: string, n: number): void { }
declare function foo<...T>(cb: (...cbArgs: T) => void, ...args: T): [...T];

foo(callback, "hello", 0, 1);

fooは何を返しますか？ 私の言いたいことは、ジェネリックルールはジェネリック型とジェネリックシグネチャで同じであると人々が期待しているということですが、ジェネリック型をより表現力豊かにする場合、型引数の推論にはそれを処理する方法が必要です。 これは、型引数の推論が難しいケースを正式に識別し、これらの場合にユーザーに明示的な型引数を渡すように要求するだけの問題である可能性があります。

私の意見では、あなたの選択肢1の方が良いと思います。 個人的には、タプル型をRESTパラメーターとして使用することは見ていません。 Restパラメーターは可変長であると想定されているため、配列型またはREST型パラメーターのみを許可する必要があると思います。 また、型システムにすでに存在するものに関連付けられていない、型の抽象的なシーケンスであるREST型パラメーターの概念も気に入っています。

タプルに関する私の哲学は、タプルは長さがわかっている配列値のサブセットを表すというものです。 これらの配列値は実際のランタイムエンティティです。 型の抽象的なシーケンス（たとえば、署名内のパラメーターのシーケンス）を表す一種の型システムデバイスとしてそれらを使用するという考えは好きではありません。 ただし、RESTタイプのパラメーターをタプルに分散できるかどうかは別の話です。

タプルはより強力で、より多くのユースケースを解決できるため、タプルの提案が好きです。タプルは単なる配列であり、RESTパラメーターを使用して関数を呼び出すと、配列を拡散できるため、タプルをRESTパラメーターとして拡散できることも非常に直感的です。 そうすれば、型システムは私のコードの理解とよりよく一致するでしょう。

@JsonFreemanの場合、fooは[string, number, number]を返します。これは、 ...argsから推測され、推測されるcbタイプは(string, number, number) => voidあり、渡されたコールバックは最後の引数を無視します。 TSとJSの両方で非常に一般的です。

型の抽象的なシーケンスを表すためにそれらを一種の型システムデバイスとして使用するという考えは好きではありません

それはまさに彼らが何であるかです、JSはタプルについて知りません、TSだけです。 TSの場合、タプルは一連のタイプです。

タプルベースのアプローチも好きです。 特に、次のような互換性のある関数シグネチャを使用できる場合は、次のようになります。

// all are equivalent
(a: A, b: B, c: C) => R;
(a: A, b: B, ...rest: [C]) => R;
(a: A, ...rest: [B, C]) => R;
(...args: [A, B, C]) => R;

// this is more complicated 
(a: A, ...rest: T[]) => R;
(...args: [A, ...T]) => R; // no in current syntax

後者は現在の構文では表現できませんが、＃6229を採用すれば表現できます。
したがって、私にとって適切な方法は、タプルを使用し、タプルを統合してより多くの表現を行うことだと思われます。 より表現力豊かなタプルがなければ、タプルとしてのTの長さが開いているため、 [...T, ...T]ようなものを作成するのは困難です。

ご例えば@JsonFreeman、@Pajnはその私の理解と正確に示した-これらの型を推論で目に見える問題なしはありません。

@JsonFreemanその構文を使用したほうがいいです

declare function foo<T>(cb: (...cbArgs: T) => void, ...args: T): T;
declare function foo<T>(cb: (...cbArgs: T) => void, ...args: T): [...T]; // same

うーん、おそらくそれはいくつかのあいまいさをもたらすかもしれません：

declare function foo<T>(...args: T): T;
foo(1); // T is [number] or number[]?

// however, here it'd be more explicit
declare function foo<T>(...args: T[]): T[];
foo(1); // T is number[]

// and here
declare function foo<T>(...args: [...T]): T;
foo(1); // T is [number]

タプルでREST型パラメーターを拡散するというアイデアを後回しにすることができました。 しかし、REST型パラメーターを暗黙的にタプルとして解釈する必要があるかどうかはわかりません。 @Pajnの例は、

@Igorbek最初の例のあいまいさについては正しいです。 ただし、3番目の例にも問題があります。 number, stringようなシーケンスが与えられると、署名の2つの可能なインスタンス化があります。 つまり、 (arg1: number, arg2: string) => [number, string]と(arg1: [number, string]) => [number, string] （例のために暗黙のタプル解釈を採用）です。

暗黙のタプル解釈に関するもう1つの奇妙な点は、これです。 number, stringにインスタンス化されているREST型パラメーターTがあるとします。 ここで、それらを型引数Foo<T>として渡すとします。 Foo<...T>がFoo<number, string>あるのに対し、それはFoo<[number, string]>として解釈されますか？ これには、spread演算子を型システムに拡張することになるため、議論があります。 しかし、それでもタプルバージョンはFoo<[...T]>として表される方がいいです

私をクレイジーと呼んでください、しかし私は使用するという考えでいくつかの根本的な欠陥を感じます
タプル。 タプルタイプをあまりにも多くの人に広めようとするとどうなりますか
パラメーター？ このような？

declare function foo<T>(...args: [...T]): void
foo<[number]>(1, 2)

また、型パラメータが間違った型であるか、で使用されている場合はどうなりますか
異常な、潜在的に誤った場所？

// 1. unusual place
declare foo<T>(x: T, ...ys: [...T]): void

// 2. bad type
declare foo<T>(...xs: [...T]): void
foo<number>(2)

最初の例は、Function＃applyに直接関連しています（
エラー）、2番目はコンパイルに失敗する明らかでない間違いです、
Intellisenseで検出するのは簡単ではありません。

日、2016年2月28日には、午前3時04分ジェイソン・フリーマン[email protected]は書きました：

暗黙のタプル解釈に関するもう1つの奇妙なことは、次のとおりです。
数値、文字列にインスタンス化されるRESTタイプパラメータTがあります。
さて、それらを型引数として渡すとしましょう、Foo。 それは
Foo <[number、string]>として解釈されますが、Foo <... T>はFooです文字列>？

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

@JsonFreeman

ただし、3番目の例にも問題があります。 number, stringようなシーケンスが与えられると、署名の2つの可能なインスタンス化があります。 つまり、 (arg1: number, arg2: string) => [number, string]と(arg1: [number, string]) => [number, string] （例のために暗黙のタプル解釈を採用）です。

明らかな私の3番目の例から、それは(...args: [number, string]) => [number, string]としてのみ解釈できます：

declare function foo<T>(...args: [...T]): T;
foo(1, "a"); // T is [number, string]
const result: [number, string] = foo<[number, string]>(1, "a");

// however, it is assignable to/from the following signatures:
const f1: (arg1: number, arg2: string) => [number, string] = foo<[number, string]>;
const f2: (arg1: number, ...rest: [string]) => [number, string] = foo<[number, string]>;

暗黙のタプル解釈に関するもう1つの奇妙な点は、これです。たとえば、RESTタイプパラメーターTがnumber, stringにインスタンス化されているとします。

Tは、真のタプルであるため、 number, stringインスタンス化できません。 [number, string]である必要があります。

ここで、それらを型引数Foo<T>として渡すとします。 Foo<...T>がFoo<number, string>あるのに対し、それはFoo<[number, string]>として解釈されますか？

NS。 ただし、 <...T>使用することは、これから説明するこの特定のユースケースでは冗長に思えます（REST引数の位置付けされた型をキャッチします）。 それにもかかわらず、私たちがそれを持っているとしましょう。

これには、spread演算子を型システムに拡張することになるため、議論があります。 しかし、それでもタプルバージョンはFoo<[...T]>として表される方がいいです

その構文を使用する可能性がある場合は2つあります。

// in a signature declaration
declare function foo<[...T]>(...args: [...T]): [...T];
// and when type instantiated, so in the usage
type T = [number, string]
foo<T>();
foo<[...T]>();
// the latter can virtually be replaced as
type _T = [...T]; // which is a type operation that should produce [number, string]
foo<_T>();
// and more
type Extended = [boolean, ...T]; // [boolean, number, string]

したがって、使用法としては、 | 、 & 、 []ような型演算子にすぎません。 しかし、構文がT extends any[]またはすべてのタプルの基本型として解釈される可能性があるという宣言では、それがタプル型でなければならないことを示しています。

@isiahmeadows

タプルタイプをあまりにも多くの人に広めようとするとどうなりますか
パラメーター？ このような？

declare function foo<T>(...args: [...T]): void
foo<[number]>(1, 2); // ok, foo<[number]> is of type (...args: [number]) => void
// [1, 2] is being passed in place of args
// is [1, 2] which is [number, number] assignable to [number]? yes, with current rules
// no error

また、型パラメータが間違った型であるか、で使用されている場合はどうなりますか
異常な、潜在的に誤った場所？

// 1. unusual place
declare foo<T>(x: T, ...ys: [...T]): void
// 1. [...T] can be interpret as a type constraint "must be a tuple type"
// 2. if we call with type specified
foo<number>(1); // number doesn't meet constraint
foo<[number]>(1, 2); // argument of type 'number' is not assignable to parameter 'x' of type '[number]'
foo<[number]>([1], 2); // ok
// 3. if we call without type, it must be inferred
foo(1); // according to current rules, T would be inferred as '{}[]' - base type of all tuples
        // so, argument of type 'number' is not assignable to parameter 'x' of type '{}[]'
foo([1, 2], 2); // T is inferred as '[number, number]
                // rest arguments of type '[number]' are not assignable to rest parameters 'ys' of type '[number, string]'
foo([1], 2, 3); // T is '[number]',
                // x is of type '[number]',
                // ys is of type '[number]',
                // rest arguments are of type '[number, number]' which is assignable to '[number]',
                // no error

// 2. bad type
declare foo<T>(...xs: [...T]): void
foo<number>(2); // type 'number' doesn't meet constraint

これらのものをタプルとして表すことの利点はまだわかりません。 さらに、 <T>ではなく<...T>として宣言する必要があると思います。 前に言ったように、タプル型は、型システムの任意の長さの型シーケンスに使用するのに適切なデバイスとは見なされていません。 人々が望む表現度のためにこれが必要であると私はまだ確信していません。

もっと表現力があると思いますが、型パラメーターの位置に「spread」演算子があると、RESTパラメーターを2回持つことができないのと同じように、REST引数を1回だけキャッチするように制限されます。 したがって、 <...T>と<A, B, C>与えられると、 Tはそれらを[A, B, C]としてキャッチします。 また、 <...T, ...U>はあいまいであるため、表現できません。 [A, B, C], []または[A, B], [C]などです。

次の動作で関数を表現したいとします。

declare function foo(a: A, b: B): R;
declare function boo(c: C, d: D, e: E): U;

let combined: (a: A, b: B, c: C, d: D, e: E) => [R, U] = combine(foo, boo);

// so the signature could be:

declare function combine<R, U, ???>(
  f1: (...args: [...T1]) => R,
  f2: (...args: [...T2]) => U):
    (...args: [...T1, ...T2]) => [R, U];

// if ??? is '...T1, ...T2'
combine<R, U, A, B, C, D, E> // what will be T1 and T2 ?
combine<R, U, ...[A, B, C], ...[D, E]> // ok ? so we will preserve spread to specific positions. so then
combine<...[R, U], A, ...[B, C, D], E> // will be restricted.
// however, ES6 allows to do it with function arguments
f(1, 2, 3);
f(...[1, 2], 3);
f(...[1], ...[2, 3]);

// if ??? is 'T1 extends TupleBase, T2 extends TupleBase'
// or just '[...T1], [...T2]' as a shortcut for such constraints
combine<R, U, [A, B, C], [D, E]> // pretty explicit, and doesn't occupy spread operator for type arguments

さて、あなたがそれをどのように考えているかがわかりました。 あなたが提案しているのは、実際には私が思っていたものとは異なる機能のようです。 型パラメーターのシーケンスをキャプチャするための新しい構成を追加する代わりに、タプル型はすでに型のシーケンスを表しているため、拡散可能にする必要があります。 そうすれば、さまざまな長さの複数のタプルをより透過的な方法で渡すことができます。

javascriptでは、 function foo(...rest) { }ではなくfunction foo([...rest]) { }ようになります。

説明してくれてありがとう、それは今私にとってより理にかなっています。 それは合理的なアプローチだと思います。

@JsonFreemanその通り！

@JsonFreeman質問： [1, 2]が[number]満たす必要があるのはなぜですか？ それは私には非常に奇妙に思えます。 それが実際に機能することは非常に驚くべきことです。 型安全ではありません。

ただし、可変個引数タイプにタプルが使用されることに反対しているわけではありません（私は中立であり、正直でもあります）。

@isiahmeadowsはどのようにして[1, 2]を[number]置き換えることができないのですか？ それは間違いなくサブタイプです。 { x: 1, y: 2 }が有効な{ x: number }あるのと同じです

わかった。 部分的に譲歩しますが、引数のタプルを受け入れるFunction.prototype.applyを考慮に入れます。

interface Function<T, U, V> {
    (this: T...args: [...U]): V;
    apply(object: T, args: U): V;
}

呼び出し元があまりにも多くの引数に対してTypeErrorをスローした場合、あまりにも多くの引数を渡すと、本来のコンパイルエラーではなく、ランタイムエラーが発生します。

渡された引数が多すぎると、JS関数がTypeErrorをスローすることは非常にまれではありませんか？ いくつかの例は何ですか？

@isiahmeadowsは抽象的な例ですが、あなたが心配しているエラーは次のとおりです。

function f(x: number): void {
  // throw if too many arguments
}
f.apply(undefined, [1,2,3]); // runtime error, no compile-time error
f(1,2,3) // compile-time error and runtime error.

あれは正しいですか？

@sandersn 、引数が多すぎる場合のTypeErrorは、JSの精神に違反するものだと思います。通常、この関数に渡される実際の引数よりも正式な引数の少ない関数を渡すためです。 私たちは単にそれらを使用しません。 たとえばArray.prototype.forEach

機能カリー化はどうですか？ ラムダでは、それはおそらくはるかに一般的です
およびlodash / fp。

月、2016年2月29日には、13：45には、アナトリーRessin [email protected]書きました：

@sandersn https://github.com/sandersn、TypeErrorもオンになっていると思います
多くの議論は、JSの精神に違反するものです。
通常、実際の引数よりも形式的な引数が少ない関数を渡します。
この関数に渡されます。 私たちは単にそれらを使用しません。 例えば
Array.prototype.forEach

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

@isiahmeadows arguments.length基づくカリー化は非常に不安定で、実行時にエラーが発生しやすいと思います。 実際のカリー化は、議論の余地がありません。

var plus = x => y => x + y
console.log(plus(3)(4)) // 7
console.log(plus(3,10)(4,20)) // still 7

固定署名付きの関数をコールバックとしてどこかに渡すと、次のように考えます。 '私の関数は_少なくとも_それらの引数を期待します'

foldlようなものはどうですか？

const list = [1, 2, 3]
console.log(foldl((a, b) => a + b, 0, list))
console.log(foldl((a, b) => a + b, 0)(list))
console.log(foldl((a, b) => a + b)(0, list))
console.log(foldl((a, b) => a + b)(0)(list))

これは関数型プログラミングでは非常に一般的です。 そして最後を省略
議論はかなり一般的です。

月、2016年2月29日には、13時52分には、アナトリーRessin [email protected]書きました：

@isiahmeadowshttps ：//github.com/isiahmeadowsカリー化だと思います
aruments.lengthに基づくと、非常に不安定で、実行時にエラーが発生しやすくなります。
実際のカリー化は、議論の余地がありません。

var plus = x => y => x + y
console.log（plus（3）（4））// 7
console.log（plus（3,10）（4,20））//まだ7

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

たとえば、 mapへのコールバックとしてそれを渡したい場合（リストの処理
リストの）、あなたはおそらくそれをカレーしたいと思うでしょう。

2016年2月29日月曜日、 13 ： [email protected]は次のように書いています。

foldlようなものはどうですか？

const list = [1, 2, 3]
console.log(foldl((a, b) => a + b, 0, list))
console.log(foldl((a, b) => a + b, 0)(list))
console.log(foldl((a, b) => a + b)(0, list))
console.log(foldl((a, b) => a + b)(0)(list))

これは関数型プログラミングでは非常に一般的です。 そして最後を省略
議論はかなり一般的です。

月、2016年2月29日には、午後1時52アナトリーRessin [email protected]
書きました：

@isiahmeadowshttps ：//github.com/isiahmeadowsカリー化だと思います
aruments.lengthに基づくと、非常に不安定で、実行時にエラーが発生しやすくなります。
実際のカリー化は、議論の余地がありません。

var plus = x => y => x + y
console.log（plus（3）（4））// 7
console.log（plus（3,10）（4,20））//まだ7

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

私はそれが主にそれについてだと思います：

type T = [number, string];
var a: T = [1, "a", 2]; // valid

// in this cases tuple types or parameter types cannot be inferred:
f(...a, true); // you could think number,string,boolean were passed, but weren't
const c = [...a, true]; // you could think that is of type [number, string, boolean] but it's not
// according to current rules, the best inferred types might be [number, string, number|string|boolean]

// same manner with variadic kinds, types are constructed properly:
type R = [...T, boolean]; // [number, string, boolean]

だから私は＃6229を提案しました

[1, 2]が[number]満たすかどうかの質問は、質問して議論するのに有効な質問です。 しかし、それはスプレッド可能なタプル機能と何の関係があるのでしょうか？

タプルの可変個引数アプリケーションが余分な引数を無視する必要があるかどうかです
か否か。 このオーバーロードされた関数は、私の懸念をさらに詳しく説明するはずです。

declare function foo(x: number, ...args: string[]): void
declare function foo<T>(...args: [...T]): void
foo<[number]>(1, 2)

// This will always fail
declare function foo(x: number, ...args: string[]): void
declare function foo<T>(x: T): void
foo<number>(1, 2)

月、2016年2月29日には、18時47分ジェイソン・フリーマン[email protected]は書きました：

[1、2]が[数値]を満たすかどうかの質問は、質問するのに有効な質問です。
と討論。 しかし、それはスプレッド可能なタプル機能と何の関係があるのでしょうか？

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

そしてこれが、実用的な理由から、RESTパラメーターのようなものを好む理由です
可変個引数型。

2016年2月29日月曜日、19：00 Isiah [email protected]は次のように書いています。

タプルの可変個引数アプリケーションが余分なものを無視する必要があるかどうかです
引数かどうか。 このオーバーロードされた関数は、私の
懸念。

declare function foo(x: number, ...args: string[]): void


declare function foo<T>(...args: [...T]): void
foo<[number]>(1, 2)

// This will always fail
declare function foo(x: number, ...args: string[]): void
declare function foo<T>(x: T): void
foo<number>(1, 2)

月、2016年2月29日には、午前18時47ジェイソン・フリーマン[email protected]
書きました：

[1、2]が[数値]を満たすかどうかの質問は、質問するのに有効な質問です。
と討論。 しかし、それはスプレッド可能なタプル機能と何の関係があるのでしょうか？

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

@JsonFreemanこれは、型と配列/タプルのspread演算子のためです。 スプレッド型演算子が「指定された型A 、 B 、およびT = [A]形式で許可されている場合、 [...T, B]は[A, B] 」 （暗黙的に提案されます）その場合、配列/タプル拡散演算子と整列されません。 var a: [A]とvar b: B与えられた場合、式[...a, b]の型が[A, B]型であると証明することはできません。 タプルの現在のルールによれば、タイプ[A, A|B]であることが証明される可能性があります。
それはあなたにとって意味がありますか？ または、比較表を作成して、その不一致を強調することもできます。

@Igorbekあなたの言っていることがわかります。 最終的には、コンパイラーが処理する型について完全な知識を持っているが、値については完全な知識を持っていないという事実に起因します。 特に、この例では、値a長さが不明ですが、タイプ[A]長さは既知です。 これが、この目的でタプル型を使用することに最初は不快だった理由の1つでした。 しかし、それが深刻な問題かどうかはわかりません。

@isiahmeadowsあなたが何を求めているのかわかりますが、

タイプセーフソリューションは、他のソリューションとより一貫性があります。
引数の構文を模倣した場合の言語。

私のポイントは、RESTパラメーターを効果的に拡散している場合、次のようになります。
正確に引数タイプであり、それ以上ではありません。 カレー関数にはリターンがあります
引数の型に依存する型。 したがって、1つの引数を適用しすぎると
カリー化機能を部分的に適用すると、まったく違うものになります
タイプ。 タプルのようなRESTタイプを処理すると、代わりにランタイムエラーが発生します。
これは決して良いことではありません。

火、2016年3月1日には、午前6時07ジェイソン・フリーマン[email protected]は書きました：

@Igorbekhttps ：//github.com/Igorbekあなたの言っていることがわかります。
それは最終的に、コンパイラが完全な知識を持っているという事実から生じます
それが扱っているタイプの、しかし値の完全な知識ではありません。 の
特に、あなたの例では、値aの長さは不明ですが、
タイプ[A]の長さは既知です。 これが私が最初にいた理由の1つでした
この目的でタプル型を使用することに不快感を覚えます。 しかし、私にはわかりません
それは深刻な問題です。

@isiahmeadowshttps ：//github.com/isiahmeadowsあなたが何を求めているのかわかります
についてですが、RESTタイプのパラメーターで問題がより明確になるのはなぜですか？

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

@isiahmeadowsカリー化問題のサンプルコードを

Restタイプのパラメーター（私がすべてです）を使用したとしても、過剰な引数を許可しないことを明示的に決定する必要があると思いますが、おそらくそうすべきである

@sandersn @JsonFreeman

type FullCurry<T> = ((initial: T, xs: T[]) => T) | ((initial: T) => (xs: T[]) => T)
declare function foldl<T>(func: (acc: T, item: T) => T, initial: T, xs: T[]): T
declare function foldl<T>(func: (acc: T, item: T) => T): FullCurry<T>
declare function foldl<T>(func: (acc: T, item: T) => T, initial: T): (xs: T[]) => T

interface Function<T, R, ...A> {
    apply<U extends T>(inst: U, args: [...A]): R
    apply(inst: T, args: [...A]): R
}

function apply(reducer: (initial: number) => number): (number[]) => number {
    reducer.apply(undefined, [0, []])
}

const func = apply(foldl<number>((x, y) => x + y))

func([1, 2, 3]) // Runtime error

バリエーションも追加します。 提案からの可変個引数カレーの例を見てみましょう：

function curry<...T,...U,V>(f: (...ts: [...T, ...U]) => V, ...as:...T): (...bs:...U) => V {
    return ...b => f(...as, ...b);
}

それで、私はそれを使い始めました：

function f(a: number, b: string, c: string) { return c.toUpperCase(); }
var a: [number, string] = [1, "boo", 2]; // valid
const cf = curry(f, ...a); // cf is of type string => string
cf("a"); // runtime error

@isiahmeadowsそれらが

@Igorbek問題は可変個引数型シーケンスの表現方法ではないという点で、あなたの例は似ていると思います。 問題を引き起こすのは、それらをタプルに広げる機能です。

@JsonFreeman私がこの振る舞いに反対するのはそれだけではあり

class A {}
class B {}
class C {}

declare function foo(a: A, b: B): C;

// This should not work
let value: [A, B, C]
foo(...value)

それは明確ですか？

@isiahmeadows実際に

@JsonFreeman
私はそれがすべきではないと感じています。 それが私の最大の異議です。 もしそうなら、それは潜在的に危険だと思います。

質問： retの推定リターンタイプはどうあるべきですか？

declare function foo(a: A, b: B, c: C, d: D): D
let ret = foo.bind(...[new A(), new B(), new D()])

これは実際にはかなり重要です。

その最後の例は間違いなく機能しないようです。 function.bindが実際に正しく機能する場合は、基本的に、型のシーケンスを整列させるメカニズムが必要です。 バインドする引数の型が元の関数の引数と照合され、残りが戻り型になる、統一に似たものが必要になります。

とはいえ、提案または議論された内容では、（タプルの追加の引数が許可されているかどうかに関係なく）それを処理できるものはないようですが、何かを見逃した可能性はあります。

最大の問題は、各パラメーターの型がスプレッド型と照合される、ある種のタプルパターンマッチングを、その問題を修正するために型パラメーター（LiveScript / CoffeeScriptの引数）で実行する必要があることだと思います。 そうでなければおそらく不可能です。 そして、それがどれほど複雑かについては、それを実装するために頑張ってください。 ：笑顔：

@JsonFreeman

または、より正確に言うと、（熱心な対怠惰な意味で）厳密ではないタイプチェックが機能する必要があります。 また、自己再帰型など、他の多くの便利なものへの扉を開くので、とにかく、それはおそらく可変個引数型よりも便利な拡張機能だと思います。

// I hate this idiom.
interface NestedArray<T> extends Array<Nested<T>> {}
type Nested<T> = T | NestedArray<T>

// I would much prefer this, but it requires non-strict type checking.
type Nested<T> = T | Nested<T>[]

ありがたいことに、非厳密な型チェックは、以前はチェックに失敗したコードのみが機能するようになったという点で、純粋にノーブレークの変更である必要があります。

これは、非常に複雑な型の署名が必要になるという事実を除けば、おそらくFunction.prototype.bindの適切な型指定を妨げる最大の問題です。

それは興味深いつながりです。 しかし、私はそれらが関連しているとは確信していません。 再帰型の問題は、ジェネリックスのキャッシュポリシーと、コンパイラーでの型エイリアスの表現の結果です。 すべての情報がそこにあり、邪魔になるのはコンパイラの設計だけです。

タプルパターンマッチングの場合、タプルに対して一致する引数の数を常に把握できるとは限りません。 配列をbindの引数に分散すると、結果のコールバックにいくつ残っているかわかりません。

@JsonFreemanとは

@JsonFreeman

また、型を厳密にチェックしないと、 Function.prototype.bindその問題を簡単に修正できるほどの怠惰が可能になります。 このような怠惰があると、次のようにしてその型を実現できます（型宣言で複数のRESTパラメーターが問題ない場合を除き、それらをシーケンスするためにタプル構文が必要になります）。

interface Function {
    bind<R, T, ...X, ...Y>(
        this: (this: T, ...args: [...X, ...Y]) => R,
        thisObject: T,
        ...args: [...X]
    ): (this: any, ...rest: [...Y]) => R
}

なぜこれは推論するために非厳密な型チェックを必要とするのでしょうか？ 関数をチェックするには、残りのタイプを段階的に推測する必要があります。 次のことを考えると、次のようにチェックする必要があります。

// Values
declare function func(a: number, b: string, c: boolean, d?: symbol): number

let f = func.bind(null, 1, "foo")

// How to infer
bind<R, T, ...X, ...Y>(
    this: (this: T, ...args: [...X, ...Y]) => R,
    thisObject: T,
    ...args: [...X]
): (this: any, ...rest: [...Y]) => R

// Infer first type parameter
bind<number, T, ...X, ...Y>(
    this: (this: T, ...args: [...X, ...Y]) => number,
    thisObject: T,
    ...args: [...X]
): (this: any, ...rest: [...Y]) => number

// Infer second type parameter
bind<number, any, ...X, ...Y>(
    this: (this: any, ...args: [...X, ...Y]) => number,
    thisObject: any,
    ...args: [...X]
): (this: any, ...rest: [...Y]) => number

// Infer first part of rest parameter
bind<number, any, number, ...*X, ...Y>(
    this: (this: any, ...args: [number, ...*X, ...Y]) => number,
    thisObject: any,
    ...args: [number, ...*X]
): (this: any, ...rest: [...Y]) => number

// Infer second part of rest parameter
bind<number, any, number, string, ...*X, ...Y>(
    this: (this: any, ...args: [number, string, ...*X, ...Y]) => number,
    thisObject: any,
    ...args: [number, string, ...*X]
): (this: any, ...rest: [...Y]) => number

// First rest parameter ends: all ones that only uses it are fully spread
bind<number, any, number, string, ...Y>(
    this: (this: any, ...args: [number, string, ...Y]) => number,
    thisObject: any,
    ...args: [number, string]
): (this: any, ...rest: [...Y]) => number

// Infer first part of next rest parameter
bind<number, any, number, string, boolean, ...*Y>(
    this: (this: any, ...args: [number, string, boolean, ...*Y]) => number,
    thisObject: any,
    ...args: [number, string]
): (this: any, ...rest: [boolean, ...*Y]) => number

// Infer second part of next rest parameter
// Note that information about optional parameters are retained.
bind<number, any, number, string, boolean, symbol?, ...*Y>(
    this: (
        this: any,
        ...args: [number, string, boolean, symbol?, ...*Y]
    ) => number,
    thisObject: any,
    ...args: [number, string]
): (this: any, ...rest: [boolean, symbol?, ...*Y]) => number

// Second rest parameter ends: all ones that only uses it are exhausted
bind<number, any, number, string, boolean, symbol?>(
    this: (this: any, ...args: [number, string, boolean, symbol?]) => number,
    thisObject: any,
    ...args: [number, string]
): (this: any, ...rest: [boolean, symbol?]) => number

// All rest parameters that are tuples get converted to multiple regular
parameters
bind<number, any, number, string, boolean, symbol?>(
    this: (
        this: any,
        x0: number,
        x1: string,
        x2: boolean,
        x3?: symbol
    ) => number,
    thisObject: any,
    x0: number,
    x1: string
): (this: any, x0: boolean, x1?: symbol) => number

// And this checks

これは、非厳密な型チェックの仕組みです。 見た瞬間ではなく、必要に応じてタイプを推測します。 間違ったタイプが失敗するように、2つのパスを組み合わせることができます（そしてそうすべきです）。 例：

let f = func.bind(null, 1, Symbol("oops"))

// How to infer
bind<R, T, ...X, ...Y>(
    this: (this: T, ...args: [...X, ...Y]) => R,
    thisObject: T,
    ...args: [...X]
): (this: any, ...rest: [...Y]) => R

// Infer first type parameter
bind<number, T, ...X, ...Y>(
    this: (this: T, ...args: [...X, ...Y]) => number,
    thisObject: T,
    ...args: [...X]
): (this: any, ...rest: [...Y]) => number

// Infer second type parameter
bind<number, any, ...X, ...Y>(
    this: (this: any, ...args: [...X, ...Y]) => number,
    thisObject: any,
    ...args: [...X]
): (this: any, ...rest: [...Y]) => number

// Infer first part of rest parameter
bind<number, any, number, ...*X, ...Y>(
    this: (this: any, ...args: [number, ...*X, ...Y]) => number,
    thisObject: any,
    ...args: [number, ...*X]
): (this: any, ...rest: [...Y]) => number

// Infer second part of rest parameter
bind<number, any, number, string, ...*X, ...Y>(
    this: (this: any, ...args: [number, string, ...*X, ...Y]) => number,
    thisObject: any,
    ...args: [number, symbol /* expected string */, ...*X] // fail!
): (this: any, ...rest: [...Y]) => number

この場合、期待されるパラメーターは、深さ優先の反復を実行して、そのラウンドで最初に推測されるパラメーターである必要があります。 この場合、その検索で最初に推測されたのは文字列であり、記号は文字列に割り当てることができないため、これは失敗します。

そして、これとFunction.prototype.applyを入力しようとしたため、RESTタイプを適用するためにタプルを使用することについての私の意見が変わりました。

interface Function {
    apply<T, R, ...X>(
        this: (this: T, ...args: [...X]) => R,
        thisArg: T,
        args: [...X]
    ): R
}

他のいくつかのメモ：

1. 配列とタプルをRESTタイプのパラメーターとして拡散する方法が必要です。

ts interface Foo extends Function<void, ...string[]> {}

1. コンストラクターと呼び出し可能オブジェクトには2つの別個の型が必要であり、関数は2つの和集合です。 呼び出し可能オブジェクトは呼び出し可能インターフェイスを実装する必要があり、クラスコンストラクターは構築可能インターフェイスを実装する必要があり、ES5関数は2つの和集合を実装する必要があります。
2. Function.prototype.bindとその友人は、関数のすべてのオーバーロードをチェックする必要があります。 その作業が複数ある場合は、それらすべての和集合を返す必要があります。

ただし、例のこれらの型パラメーターは、実際にはバインド署名の型パラメーターではありません。 それらは関数型に属します。 しかし、そうです。2つのRESTパラメーターを使用したり、2つのRESTタイプのパラメーターをタプルに分散したりできれば、これを記述できるという考えです。

バインドの署名を十分に柔軟にするには、 ...Xと...Yの境界を呼び出しごとに決定する必要があります。 推測する必要があります。 ただし、署名で...Xを単独で使用する場合は問題になります。 この場合、境界は決定されていません。 例えば：

interface SomeType<T, R, ...X, ...Y> {
     someMethod(someArgs): [...X]; // No way of knowing how long X is 
}

そして、オーバーロードは関数型にとってかなり問題です。 オーバーロード間でパラメーターを混合および照合できるため、各引数で共用体型を要素ごとに使用する必要はないと思います。 それはあなたが意味したことですか？

@JsonFreeman

_TL; DR：水平方向の改行にスキップします。 新しい、より実用的なアイデアがあります。_

1. はい、私は彼らが本当にFunction自体に属していることを知っています。
2. そのような問題が、（Haskellの意味での）非厳密な型マッチングが必要だと私が言った理由です。 型を正常に解決することはできません。これを行うには、反復的な遅延検索が必要になるためです。 アルゴリズムで決定することは可能ですが、C ++のように通常は追跡する必要のないものを追跡する必要があります。
3. 2つの引数が分離している場合（例のように）、コンパイラーは文句を言う必要があります。 そして、その状況は、インターフェースなどの各可変個引数のタイプレベルの依存関係分析で検出できます。 また、簡単ではありませんが、型宣言自体を読み取るときに確認できます（実際には、その直後）。

私も考えていますが、問題のメソッドだけでこの種の状況を定義する方がもう少し実現可能かもしれません。 また、あなたがほのめかしたそのような潜在的な問題を検出することは、はるかに簡単かつ迅速になります。

interface Function<R, T, ...A> {
    // Split it up for just this method, since it's being resolved relative to the
    // method itself.
    bind[...A = ...X, ...Y](
        this: (this: T, ...args: [...X, ...Y]) => R,
        thisObject: T,
        ...args: [...X]
    ): (this: any, ...rest: [...Y]) => R
}

解決するのがはるかに難しい潜在的な他の問題があります（そして、なぜそれを_n _分割ではなく2に制限する必要があると思うのですか）：

declare function foo<...T>[...T = ...A, ...B, ...C](
    a: [...A, ...C],
    b: [...A, ...B],
    c: [...B, ...C]
): any

// This should obviously check, but it's non-trivial to figure that out.
let x = foo<
    boolean, number, // ...A
    string, symbol,  // ...B
    Object, any[]  // ...C
>(
    [true, 1, {}, []],
    [true, 1, "hi", Symbol()],
    ["hi", Symbol(), {}, []]
)

_ここでCS理論に深く入り込んでいる場合は申し訳ありません..._

はい、それは正しい考えだと思います。 きれいではありませんが、 Functionの型引数を知っているので、 bindを正しく入力する他の方法は考えられません。 究極のことは、境界を推測しなければならないということです。 また、組み合わせて爆発する可能性のある任意の数の境界ではなく、1つの境界を推測する必要があるように、2つのバケットに制限する必要があることに同意します。

私たちが考えていなかった問題がもっとある可能性があります。

@JsonFreemanもう1つの問題は、 curryようなものです。 私はそれを正しくタイプできるものをまだ思い付いていません。 そして、私ができるようになるまでにはしばらく時間がかかります。 そのようなプロセスを思い付くには、Haskellのような深刻なタイプのハッキングを行う必要があります。

ある種の提案がいくつかのBluebird関数でどのように機能するかを考えます。

interface PromiseConstructor {
    // all same type
    all<T>(promises: PromiseLike<T>[]):  Promise<T[]>;
    join<T>(...promises: PromiseLike<T>[]):  Promise<T[]>;
    // varying types
    all<...T>(promises: [...PromiseLike<T>]): Promise<[...T]>;
    join<...T>(...promises: [...PromiseLike<T>]): Promise<[...T]>;
    // this is sketchy...    ^
}

interface Promise<T> {
    // all same type
    then<U>(onFulfill: (values: T) => U): Promise<U>;
    spread<U>(onFulfill: (...values: T) => U): Promise<U>;
}
interface Promise<...T> {
    // varying types
    then<U>(onFulfill: (values: [...T]) => U): Promise<U>;
    spread<U>(onFulfill: (...values: [...T]) => U): Promise<U>;
}

上記のall<...T>(promises: [...PromiseLike<T>]): Promise<...T>;解決策はありますか？

@DerFlatulator

PromiseConstructorの私の大きなコメントを参照してください。 また、Promiseインターフェースを修正して、私の提案に少し近づけました。

interface PromiseConstructor {
    new <T>(callback: (
        resolve:
        (thenableOrResult?: T | PromiseLike<T>) => void,
        reject: (error: any) => void
    ) => void): Promise<T, [T]>;
    new <...T>(callback: (
        resolve:
        (thenableOrResult?: [...T] | PromiseLike<[...T]>) => void,
        reject: (error: any) => void
    ) => void): Promise<[...T], ...T>;

    // all same type
    all<T>(promises: PromiseLike<T>[]):  Promise<T[], ...T[]>;
    join<T>(...promises: PromiseLike<T>[]):  Promise<T[], ...T[]>;

    // varying types
    all<...T>(promises: [...PromiseLike<T>]): Promise<[...T], ...T>;
    join<...T>(...promises: [...PromiseLike<T>]): Promise<[...T], ...T>;

    // all<...T>(promises: [...PromiseLike<T>]): Promise<[...T], ...T> should
    // expand to this:
    //
    // all<T1, T2, /* ... */>(promises: [
    //     PromiseLike<T1>,
    //     PromiseLike<T2>,
    //     /* ... */
    // ]): Promise<[T1, T2, /* ... */], T1, T2, /* ... */>;
    //
    // This should hold for all rest parameters, potentially expanding
    // exponentially like ...Promise<[Set<T>], ...Thenable<T>> which should
    // expand to something like this:
    //
    // Promise<[Set<T1>], Thenable<T1>, Thenable<T2> /* ... */>,
    // Promise<[Set<T2>], Thenable<T1>, Thenable<T2> /* ... */>,
    // // etc...
}

interface Promise<T, ...U> {
    // all same type
    then<V>(onFulfill: (values: T) => V): Promise<[V], V>;
    spread<V>(onFulfill: (...values: T) => V): Promise<[V], V>;

    // all same type, returns tuple
    then<...V>(onFulfill: (values: T) => [...V]): Promise<[...V], ...V>;
    spread<...V>(onFulfill: (...values: T) => [...V]): Promise<[...V], ...V>;

    // varying types
    then<V>(onFulfill: (values: [...U]) => V): Promise<[V], V>;
    spread<V>(onFulfill: (...values: [...U]) => V): Promise<[V], V>;

    // varying types, returns tuple
    then<...V>(onFulfill: (values: [...U]) => [...V]): Promise<[V], ...V>;
    spread<...V>(onFulfill: (...values: [...U]) => [...V]): Promise<[V], ...V>;
}

[...Foo<T>]が[Foo<T1>, Foo<T2>, /*... Foo<TN>*/]場合、 [...Foo<T,U>]は構文エラーですか、それとも組み合わせ展開ですか？

@DerFlatulator

1. TまたはUがRESTパラメーターである場合、通常どおりに展開されます。 TがRESTパラメーターであるとすると、 [Foo<T1, U>, Foo<T2, U>, /*... Foo<TN, U>*/]ます。
2. 両方がRESTパラメーターであり、それらの長さを正しく推測できる場合は、組み合わせ展開である必要があります（Tの長さ×Uの長さ）。
3. どちらもRESTパラメーターでない場合は、構文エラーです。

実用上の理由から、3つ以上のRESTパラメーターに強く反対し、残りのパラメーターを分割する必要がある場合は、メソッドごとにのみ分割する必要があることに注意してください。 このようなもの：

interface Function<R, T, ...A> {
    // Split it up for just this method, since it's being resolved relative to the
    // method itself.
    bind[...A = ...X, ...Y](
        this: (this: T, ...args: [...X, ...Y]) => R,
        thisObject: T,
        ...args: [...X]
    ): (this: any, ...rest: [...Y]) => R
}

_（誰かがより良い構文を思い付くことができれば、私はすべての耳です。私はそれが好きではありませんが、視覚的に矛盾しないものを思いつくことはできません。）_

@isiahmeadows

2.の場合、拡張はどのような順序で行われますか？

[
Foo<T1, U1>, Foo<T2, U1>, /*... */ Foo<TN,U1>,
Foo<T1, U2>, Foo<T2, U2>, /*... */ Foo<TN,U2>,
/* ... */
Foo<T1, UN>, Foo<T2, UN>, /*... */ Foo<TN,UN>
]

または逆に：

[
Foo<T1, U1>, Foo<T1, U2>, /*... */ Foo<T1,UN>,
Foo<T2, U1>, Foo<T2, U2>, /*... */ Foo<T2,UN>,
/* ... */
Foo<TN, U1>, Foo<TN, U2>, /*... */ Foo<TN,UN>
]

このあいまいさは混乱を引き起こしませんか？ おそらく、1つの次元に制限するのが賢明でしょう。

分割構文の代替案：

interface Function<R, T, ...A> {
    bind<[...X, ...Y] = [...A]>(
        this: (this: T, ...args: [...X, ...Y]) => R,
        thisObject: T,
        ...args: [...X]
    ): (this: any, ...rest: [...Y]) => R
}

@DerFlatulator

私は2番目を期待します。 そして、それが一貫してそれである限り、人々はすぐにそれに慣れてしまうので、それがあまりにも多くの混乱を引き起こすことはないと思います。 それはまた、彼らが何をしているのかを知っている人々、またはそもそも必要性を疑うべき人々によってのみ実際に遭遇するであろう珍しいエッジケースです。

私はまた、あなたが最初の部分を拡張し、次に最初の部分の各部分について2番目を拡張しているときにそれを見ています。 この擬似コードのように：

for (let TT of T) {
  for (let UU of U) {
    expand(TT, UU);
  }
}

上記のアイデアのいくつかを繰り返します...

interface Function<TReturn, TThis, ...TArgs> {
    bind<
        [...TBound, ...TUnbound] = [...TArgs],
        TNewThis
    >(
        thisObject: TNewThis,
        ...args: [...TBound]
    ): Function<TReturn, TNewThis, ...TUnbound>
}

ここで、 [...TBound, ...TUnbound] = [...TArgs]長ために有効です...TBoundの長さから知られているargs 。 また、 TThisのタイプを変更することもできます。

このアプローチの問題の1つは、 thisバインドできるのは1回だけであるということです。たとえば、次のようになります。

interface IFoo { a: number }
interface IBar extends IFoo { b: boolean }
function f(a: number) { }

let x = f.bind(<IBar>{ a: 1, b: false }, 2); // inferred type: Function<number, IBar>
let y = x.bind(<IFoo>{ a: 1 }) // inferred type: Function<number, IFoo>

yの推定タイプは正しくありません。 Function<number, IBar>である必要があります。 これが問題になるかどうかはわかりませんが、それを解決するには、 <T>構文にロジックを導入する必要があります。

オプション1

interface Function<TReturn, TThis, ...TArgs> {
    bind<
        [...TBound, ...TUnbound] = [...TArgs],
        TNewThis = TThis is undefined ? TNewThis : TThis
    >(
        thisObject: TNewThis,
        ...args: [...TBound]
    ): Function<TReturn, TNewThis, ...TUnbound>;
}

オプション2

interface Function<TReturn, TThis, ...TArgs> {
    bind<
        [...TBound, ...TUnbound] = [...TArgs],
        TThis is undefined,
        TNewThis
    >(
        thisObject: TNewThis,
        ...args: [...TBound]
    ): Function<TReturn, TNewThis, ...TUnbound>;

    bind<
        [...TBound, ...TUnbound] = [...TArgs],
        TThis is defined
    >(
        thisObject: any,
        ...args: [...TBound]
    ): Function<TReturn, TThis, ...TUnbound>;
}

ただし、それはこの提案の範囲外である可能性があります。

型拡散演算子を使用してこのような拡張を許可するべきではないと思います。 スプレッド演算子は、配列スプレッド演算子およびオブジェクト/プロパティスプレッド演算子と完全に一致する「ブラケットリムーバー」と考えています（ステージ2の提案）。 比較してください：

let a =        [1, 2];
let b = [0, ...a     , 3];
//      [0, ...[1, 2], 3]
//      [0,     1, 2 , 3]  // removed brackets

let c =               { a: 1, b: "b" };
let d = { e: true, ...c               , f: 3 };
//      { e: true, ...{ a: 1, b: "b" }, f: 3 };
//      { e: true,      a: 1, b: "b"  , f: 3 };

新しい型のセットを構築するためにそれを拡張することを提案しています：

<...T> = <A, B, C>
...U<T> = <U<A>, U<B>, U<C>>

全く違う操作です。 必要に応じて、次のような高次の構造でモデル化できます。

<...(from R in T select U<R>)> // linq-like
<...(T[R] -> U<R>)> // ugly

@Igorbek演算子を使用して、何を展開するかを決定するのはどうですか？

interface PromiseConstructor {
    all<
      ...T, 
      [...TThen] = ...(PromiseLike<@T> | @T)
    >(
      promises: [...TThen]
    ): Promise<[...T], ...T>;
}

...Foo<<strong i="9">@T</strong>, U>は[Foo<T1,U>, /*...*/, Foo<TN,U>]ます。

...(PromiseLike<@T> | @T)はに展開されます
[PromiseLike<T1>|T1, /*...*/, PromiseLike<TN>|TN]

いくつかの構文の選択肢：

• ...Foo<&T,U>
• (T) Foo<T,U>
• (...T => Foo<T,U>)
• for (T of ...T) Foo<T,U>

ここで@Igorbekに同意します。 少なくともこの段階では、可変個引数型パラメーターのより基本的な問題を解決しようとしていることを考えると、型のシーケンスのマッピングは優先事項のようには見えません。

私はそれを禁止することにそれほど問題はありません（少なくとも最初は）。なぜなら、その振る舞いはかなり一義的であり、2人の異なる人々が2つの非常に異なることを期待するかもしれないからです。 TypeScriptは最初に高次の型モデルを持っている必要があるので（ある意味でmapが型にpingを実行する）、少なくとも今のところ@Igorbekに同意します。 そして、より高次のタイプは、あなたがただボルトで留めることができるものではありません。

だから間違いなく：+1：それを禁止するために、おそらくかなり長い間。 TypeScriptは機能的でタイプセーフな型システムを使用していないため、持っているのは良いことですが、実装は非常に複雑で、完全にハックする必要があります。

少し遅れて来ますが、 @ Igorbekにも同意します。 ＃1336で行った私のコメントを繰り返し、明確な「pack」および「unpack」演算子を持つC ++パラメーターパッキングからアイデアを借りています。

タイプをタプルにパックすることは、Typescriptのspread演算子の使用法と一致しているようです。

let [x, y, ...rest] = [1, 2, 3, 4, 5] // pack
foo(...params) // unpack
let all = [1, 2, ...other, 5] // unpack

// keep in mind this is already implemented, which kind of similar to mapping types
function map(arr) { ... }
let spreadingmap = [1, 2, ...map(other), 5];

これにより、 <...T_values> = [T1, T2, T3, etc...]の推論がはるかに簡単になります。

C ++はパックにspread演算子を使用し、アンパックに省略記号を使用しますが、両方にspreadを使用すると、Typescriptとの一貫性が高まります。

module Promise {
  function all<...T_values>(   // pack into a tuple of types, conceptually identical to rest parameters
      values: [ (<PromiseLike<T*>> ...T_values) ]  // unpack, cast, then repack to tuple
  ): Promise<T_values> // keep it packed since T_values is a tuple of whatever types
}

@isiahmeadows @JsonFreemanマッピングなしでこのすべてのポイントは何でしょうか？

また、＃1336で提起されたように、可変個引数Array.flattenどうですか？

@jameskeaneその前半は最初のアイデアでしたが、ミドルレストパラメーター（一部のAPIにはあります）の場合については説明していません。

function foo<...T>(a: Foo, b: Bar, ...rest: [...T, Baz]): Foo;

また、 Function.prototype.applyとFunction.prototype.call比較も十分にカバーしていません。

＃1336に関しては、これを介して同様に実装される可能性があります。

angular.module('app').controller(['$scope', function($scope: ng.IScope) { /*etc...*/ }]);

interface IModule {
  controller(injectable: [...string[], () => any]);
}

私は追いついてきて、タプル型が厳密な長さであると素朴に想定していることに気づきました。 どのimoが最も直感的です。 では、厳密な長さのタプル型（＃6229）を取得すると仮定すると、問題は何ですか？

@isiahmeadows上記のミドルレストパラメーターの場合の例では、厳密な長さのタプルを使用することで解決されませんか？ arr = [...other, 123]展開するスプレッドと同じように...rest: [...T, Baz]読んでいます。 これはあなたがcurryで提起したのと同じ問題ですよね？

applyとcallについては、交差する型でカバーされていませんか？ （とにかく、 Functionインターフェイスに型を設定することの価値を実際に理解しているわけではありません）。

// as in
const t: [any, string] & [number, any] = [1, "foo"]

interface Function<R, T, ...A> {
    bind<...Y, ...Z>(
        this: (this: T, ...args: A & [...Y, ...Z]) => R, // tricky bit, luckily intersecting tuples is pretty easy
        thisObject: T,
        ...args: Y
    ): (this: any, ...rest: Z) => R
}

@jameskeane

現在の可変個引数の提案は、＃6229が実際に受け入れられることを前提としています（つまり、タプルはデフォルトで厳密です）。

func.apply 、 func.bind 、 func.call 、および_.curry場合、唯一の問題はfunc.bind 、 _.curry 、と友達、またはより一般的には部分適用を使用するもの。 また、分離するRESTパラメーターを選択できる必要があります。これは、実際にはメソッドごとにのみ実行できます。

callとapplyは非常に簡単です。

type Callable<R, T, ...A> = (this: T, ...args: [...A]) => R;

interface Function<R, T, ...A> {
    call(this: Callable<R, T, ...A>, thisArg: T, ...args: [...A]): R;
    apply(this: Callable<R, T, ...A>, thisArg: T, args: [...A]): R;
}

bindはもっと難しいでしょう。 分割パラメータは、最初の分割された半分が完全に解凍されるまで、現在の場合のように熱心にではなく、必要に応じて一致させる必要があります。 これは構文として実装する必要があります。これにより、コンパイラはそれを区別し、何も評価せずに型を正しく識別できます。

// Function.prototype.bind
type Callable<R, T, ...A> = (this: T, ...args: [...A]) => R;
type Constructible<R, ...A> = new (...args: [...A]) => R;

interface Function<R, T, ...A> {
    // my proposed syntax for splitting a rest parameter
    bind[[...A] = [...X, ...Y]](
        this: Callable<R, T, ...A>
        thisArg: T,
        ...args: [...X]
    ): Callable<R, any, ...Y>;

    bind[[...A] = [...X, ...Y]](
        this: Constructible<R, ...A>
        thisArg: T,
        ...args: [...X]
    ): Constructible<R, ...Y>;

    bind[[...A] = [...X, ...Y]](
        this: Callable<R, T, ...A> & Constructible<R, ...A>
        thisArg: T,
        ...args: [...X]
    ): Callable<R, T, ...Y> & Constructible<R, ...Y>;
}

curryは、 f(1, 2, 3) === f(1, 2)(3) === f(1)(2, 3) === f(1)(2)(3)ことを知っている必要があるため、非常に困難です。 。 bindように、RESTパラメーターを2つに分割する機能が必要なだけでなく、メソッドごとに非常にプリミティブなパターンマッチングを実行する機能も必要です。

interface Curried<R, T, ...XS> {
    // none passed
    (): this;

    // all passed
    (this: T, ...args: [...XS]): R;
}

interface CurriedMany<R, T, X, ...YS> extends Curried<R, T, X, ...YS>  {
    // penultimate case, constraint that ...YS contains no parameters
    [[...YS] = []](arg: X): Curried<R, T, X>;

    // otherwise, split rest into ...AS and ...BS, with `A` used as the pivot
    // (basically, default case)
    [[...YS] = [...AS, A, ...BS]](
        ...args: [X, ...AS]
    ): CurriedMany<R, T, A, ...BS>;
}

function curry<R, T>(f: (this: T) => R): (this: T) => R;
function curry<R, T, X>(f: (this: T, arg: X) => R): Curried<R, T, A>;
function curry<R, T, X, ...YS>(
    f: (this: T, arg: X, ...args: [...YS]) => R
): CurriedMany<R, T, X, ...YS>;

curryを追加してもチューリング完全になるとは思いませんが、近いでしょう。 それを妨げる主なものは、特定の型の専門分野に一致する能力だと思います（C ++、Scala、Haskell、チューリング完全型システムを備えた3つの言語はすべて持っています）。

@sandersn上記の例は表示されませんでしたが、可変個引数パラメーターの制約について質問できますか？

次の例を考えてみましょう。

interface HasKey<T> {
    Key(): T;
}

class Row<...T extends HasKey<X>, X> {
    // ...
}

_ちなみに、 Xをリストする必要があるという要件を削除する可能性については、 https： //github.com/Microsoft/TypeScript/issues/7848を参照して

ここで、制約が次のいずれであるかについて、あいまいさが生じる可能性があります。

1. (...T) extends HasKey<X>または
2. ...(T extends HasKey<X>)

この例では、2を想定しています。

これらの種類の制約（1および/または2）は可能ですか？

@myitcv 2がおそらく最善のルートですが、制約をチェックするために既存のロジックを再利用することは理にかなっています。

さて...私はちょうど何かに気づきました：可変個引数型を含む配列はどのようになりますか？ より具体的には、以下のargはどのタイプですか？

function processItems<...T>(...args: [...T]): void {
    for (const arg of args) { // Here
        process(arg);
    }
}

argsの要素タイプは何であるかを尋ねていると思います。 タプルの場合、これは通常、要素の共用体タイプであると思います。 私はそれをタイプするより良い方法を考えることができません。

@sandersnこの機能のステータスについてコメントできますか？ たくさんの議論があったように感じますが、その機能について明確な計画があるようには思えませんが、それは正しいですか？

@JsonFreeman私は具体的にargが何であるかを尋ねていました。 私の意見では、それがあるべきany私のオリジナル例えば、およびItem<T>以下で（とT F-有界）：

function processItems<...T extends Item<T>>(...args: [...T]): void {
    for (const arg of args) { // Here
        process(arg);
    }
}

これは、タイプをローカルで解決できるようにするためです。 事前に型がわからない場合は、関数を呼び出すたびに関数内で型を計算する必要がないため、コンパイルが大幅に高速化されます。 単一の引数の型だけが必要な場合は、 typeof arg十分であり、おそらく短くなることに注意してください。

申し訳ありませんが、元の例では、タイプはT必要があります。 実際、2番目の例では、Tである必要があると思います。

私は2番目にItem<any>を意味しました...ごめんなさい。

Tである必要があると言ったとき、Tはタイプであると想定していましたが、この機能の要点は、Tがタイプではないということだと思います（私は思います）。 そうですね、あなたの例ではanyとItem<any>になるはずです。

しかし、もっと広く言えば、チームが2.0以降でこの機能をどれほど積極的に検討しているかに興味があります。 私は強い意見を持っていません、ただ疑問に思っています。

必ずしもTである必要はないと思うのは、 Tが何であるかがわからないためです。 もちろん、可変個引数Tが可変個引数型リストの単一の型を表すか、拡散された場合はリスト自体、つまりTが渡されるすべての引数のサブタイプであることを意味する場合を除きます。引数...T 、および[...T]はT[]割り当てることができます。

または、すべての不明確な専門用語で私が何を意味するかを明確にするために、コードに関して私が何を意味するかを次に示します。

// To put it into code
function foo<...T>(list: [...T]): void {
    // This is allowed
    let xs: T[] = list

    // This is allowed
    let list2: [...T] = list

    // This is not allowed
    let list1: [...T] = xs

    // This is allowed
    let item: ?T = null

    // This is not allowed, since it's not immediately initialized
    let other: T

    for (let arg of args) {
        // This is allowed
        let alias: T = arg

        // This is allowed
        let other: ?T = arg

        // This is allowed, since `item` is defined upwards as `?T`
        item = arg

        // This is allowed, since you're doing an unsafe cast from `?T` to `T`.
        alias = item as T
    }
}

しかし、それはおそらくもっと理にかなっているでしょう、そしてそれははるかに柔軟でしょう。

それはまだ私たちの便利なリストにありますが、それは主に図書館の作者に興味があり、まともな回避策（_n_オーバーロード）があるので、私は積極的に取り組んでいません。 推測しなければならないのであれば、2.1は可能ですが、可能性は低いと思います。

オブジェクトのREST / Spread（＃2103）を適切にサポートすることを約束した場合、可変個引数の種類は、型を拡散して一度にすべてを実行することを正当化するのに十分近い可能性があります。 （スプレッドタイプは、 { ...T, x: number, ...U, y: string, ...V }ように見えるオブジェクトタイプのバリアントです。）

n overloads回避策は、クラスやインターフェイスでは機能しないことに注意してください。これは、この機能に特に関心があります。

@sandersn 「_n_overloads」のプルリクエストは、 this入力を使用して、関数のbind 、 apply 、およびcallに招待されますか？ これは多くの人にとって許容できる一時的な妥協案であり、一部のプロジェクトの過程でかなりの数のバグを見つける可能性があると思います。

@isiahmeadows

必ずしもTである必要はないと思うのは、Tが何であるかわからないからです。

Tは可変個引数型のタプル型であるという合意があったように私には思えました。 元の例では、 arg型はタプル要素の型と同じになります（ @JsonFreemanが「要素の共用体型」と述べたように）：今のところ、typescriptがタプルを残りとして使用することをサポートしていると想像してくださいタイプ（＃5331）。

function processItems<...T>(...args: T): void {
  for (const arg of args) { // Here - arg:number|string|boolean
    const other: ??? = arg; // I think the issue is, how to _represent_ this type?
  }
}
processItems(1, 'foo', false); // T is tuple [number, string, boolean]

この提案とは別に、タプルの「要素タイプ」を表す方法があるはずだと思います。 これは、スプレッドの別の用途、つまり上記のように...T :: number|string|booleanます。 タプル型を拡散すると、その要素型になります。

for (const arg of args) {
  const cst: ...T = arg;
}

// also, even without variadic types...
type Record = [number, string];
function foo(args: Record) {
  for (const arg in args) {
    const cst: ...Record = arg;
  }
}

これを念頭に置いて、他の例：

function foo<...T>(...list: T): void {
  let xs: T[] = [list, list] // array of the variadic tuple type

  // This is allowed
  let list5: (...T)[] = [...list]

  // This is *not* allowed
  let list2: [...T] = list

  // This is not allowed
  let list1: [...T] = xs

  // This **is** allowed
  // single element tuple, of variadic union
  // i.e. with number|string|boolean
  //      list4 = [1] or list4 = ['foo'] or list4 = [false]
  let list4: [...T] = [list[n]]

  // This **is**  allowed
  let other: T;

  // This is allowed
  let another: ...T;

  for (let arg of args) {
    another = arg; // allowed, if spreading the tuple is the union type

  }
}

私の当初の目標を見失うことなく、強く型付けされたPromise.all欲しかった...

declare module Promise {
  function all<...T>(promises: Promise<...T>[]): T; // means promises is an array of promises to the union type, not what I wanted.

  // Then we need something like, which is now very confusing
  function all<...T>(promises: [...Promise<T*>]): T; 
}}

@sandersn他の要求された機能がこれに依存し始めているので、優先順位を上げることができるでしょうか？ bind 、 callなどのタイピングはこれに依存し、ESバインド構文が出てくるかどうかはそれに依存するので、今では風変わりなライブラリの作者がいつもあなたを悩ませているよりもこれに乗っています。 :)

これを追加するのが特に建設的であるというわけではありませんが、これら2つの機能が2.1になったらとても嬉しいです。 私は少なくとも1つのライブラリ（RxJS）を知っています。これらの機能によってコードベース自体が改善されるだけでなく、コードの消費も大幅に軽減され、バグが発生しやすくなります（Angular 2を使い始める3人に1人は、インポートがないために噛まれます。監視可能なプロトタイプにパッチが適用されているオペレーターの場合）。 これは、保守可能な関数型コードを書きたいと考えている人々にとって、本当に画期的な機能になるでしょう。

これを使用して、 _.extend完全な型定義を提供できますか？その戻り型はすべてのパラメーターの共通部分です。

declare module underscore {
  function extend<A, B, C, D, ...>(a: A, b: B, c: C, d: D, ...): A&B&C&D&...;
}

現状ではありません。 可変個引数の種類の新しい演算子（おそらく＆と呼ばれる）の詳細を示す提案の拡張が必要です。 @kitsonkは、このコメントで、この演算子を以前に提案しました。
現在、この機能は他のいくつかのすぐに重要なものの下にあるので、私はしばらくこの提案を見ていません。

完全な可変個引数の種類を提供するわけではありませんが、＃10727はソリューションの一部です（そして、私たち（@dojo）が抱える課題に対処する可能性があります）。

聞いてよかった！ それはまだ実際には可変個引数の種類ではありませんが。 :(たとえば、今週Object.assignと入力しようとすると、ここまで到達しました。

interface Object {
  // binary version
  assign<T,U>(target: T, source: U): { ...T, ...U };
  // variadic version: bind a variadic kind variable ...T
  // and then spread it using SIX dots
  assign<...T>(...targets: ...T): { ......T };
}

「6ドット」構文は、タプルの種類の変数のオブジェクトスプレッドであることに注意してください。これについては、上記では実際には説明していません。

@sandersn

ではObject.assignがその目標を変異させるため、特に、それは（あなたは、このための基準点を持っている必要があるだろう）、この方法を入力し、技術的に（あまりにもinferrably弱い少しはあるが）のサブセットをキャプチャすることができます：

assign<T>(target: T, ...sources: Partial<T>[]): T;

それに関する不具合は、ターゲットを変更し、その構造タイプを所定の位置に変更することです。

@isiahmeadowsの場合、推論によりTがsourcesアカウンティングタイプなしでtargetタイプに修正されます。 非可変バージョンで今すぐ試すことができます：

declare function _assign<T>(target: T, source: Partial<T>): T;
_assign({}, { a: 10 }); // T is {}

すでに述べたように、 assignは_スプレッドタイプ_＃10727を使用し、次のように定義できます。

// non variadic
declare const assign: {
  <T>(target: T): T;
  <T, S>(target: T, source: S): {...T, ...S};
  <T, S1, S2>(target: T, source1: S1, source2: S2): {...T, ...S1, ...S2};
};
// variadic
declare function assign<T, [...S]>(target: T, ...sources: [...S]): {...T, ...[...S]};

_注：私はまだタプルベースの構文[...T]を主張していますが、これは私にとってはるかに意味があります。_

@sandersnところで、可変個引数の種類がいつ上陸するかについての更新はありますか？ 2.2でそれを見るチャンスはありますか？
そして、構文に関して、あなたはまだ構文に関するフィードバックを受け入れますか、それともあなたはすべてそれに同意しますか？

構文と低レベルのセマンティクスには、まだ明確なコンセンサスがありません。

火、2016年12月13日には、13時26分イゴールOleinikovの[email protected]は書きました：

@sandersn https://github.com/sandersnところで、いつ更新されますか
可変個引数の種類が上陸する予定ですか？ 2.2でそれを見るチャンスはありますか？
そして、構文に関して、あなたはまだ構文に関するフィードバックを受け入れますか？
あなたはすべてそれに同意しますか？

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/5453#issuecomment-266819647 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AERrBIa5fE8PSk-33w3ToFqHD9MCFoRWks5rHuM5gaJpZM4GYYfH
。

この問題の状況について何か考えはありますか？

それで、あなたが考えているオプションは何ですか？ これはチームの議題ですか？ それは私が繰り返し遭遇する型システムの唯一の弱点です。 私には2つのユースケースがあります。 単純で複雑ですが、より一般的なものです。

簡単なのは、タプル型によってのみサブタイプ化できるTuple extends any[]スーパータイプを追加することです。 スプレッドはany[]サブタイプである必要があるため、これは機能します。

declare interface Plugin<A: Tuple, P> {
  (...args: A): P | Promise<P>
}

const p: Plugin<[string, { verbose: boolean }], int> =
  (dest, { verbose = false }) => 4

現時点では、 ...args: T[]は署名の最後でのみ許可されています。

複雑なユースケースでは、署名内のどこでも合法であるために...args: Tupleが必要になります（タプルは固定長であるため、問題ありません）。

/**
 * Takes a function with callback and transforms it into one returning a promise
 * f(...args, cb: (err, ...data) => void) => void
 * becomes
 * g(...args) => Promise<[...data]>
 */
function promisify<A extends Tuple, D extends Tuple, E>
    (wrapped: (...args: A, cb: (error: E, ...data: D) => void) => void)
    : ((...args: A) => Promise<Data>) {
  return (...args) => new Promise((resolve, reject) =>
    wrapped(...args, (e, ...data) =>
      e ? reject(e) : resolve(data)))
}

const write: ((fd: number, string: string, position?: number, encoding?: string)
              => Promise<[number, string]>) =
  promisify(fs.write)

ええ、私は昨日TypeScriptを使い始めたばかりで、関数をラップするために使用している単一のデコレータのために、関数を自動的に入力することはすでに不可能になっています（もちろん手動で入力することもできます）（これが最初のことです）私はから始めてみました！）：

function portable(func) {
    return function(...args) {
        if (this === undefined) {
            return func(...args)
        } else {
            return func(this, ...args)
        }
    }
}

事実上、デコレータが行うのは、関数をメソッドとしても呼び出せるようにすることです。これにより、関数をメソッドとしてアタッチして同じように機能させることができます。基本的な例として、 Arrayプロトタイプにパッチを適用する悪い例を示します。 flatMap基本バージョンで：

function _flatMap<T, R>(
    array: T[],
    iteratee: (item: T) => R[]
): R[] {
    let result: R[] = []
    for (const item of array) {
        for (const value of iteratee(item)) {
            result.push(value)
        }
    }
    return result
}

const flatMap = portable(_flatMap)
Array.prototype.flatMap = flatMap

flatMap([1,2,3,4], x => [x, x])
// Is the same as
[1,2,3,4].flatMap(x => [x, x])
// Is the same as
flatMap.apply([1,2,3,4], [x => [x, x]])
// Is the same as
flatMap.call([1,2,3,4], x => [x, x])

flatMap （ _flatMap ）のタイプが次のとおりであることは明らかです。

function flatMap<T, R>(this: T[], iteratee: (item: T) => R[]): R[]
function flatMap<T, R>(this: undefined, array: T[], iteratee: (item: T) => R[]): R[]

ただし、 _flatMapからパラメーターの型を抽出して、装飾された関数の型定義内で使用することができないため、 typesをポータブルに追加する方法はありません。この提案で想像できます。次のように記述します。

// First argument to func is required for portable to even make sense
function portable<T, R, ...Params>(func: (first: T, ...rest: Params) => R) {
    // The arguments of calling with this is undefined should be simply
    // exactly the same as the input function
    function result(this: undefined, first: T, ...rest: Params): R
    // However when this is of the type of the first argument then the type
    // should be that the parameters are simply the type of the remaining
    // arguments
    function result(this: T, ...rest: Params): R
    function result(...args) {
        if (this === undefined) {
            return func(...args)
        } else {
            return func(this, ...args)
        }
    }
    return result
}

TypeScriptでの最初の経験を示し、可変個引数ジェネリックが重要である理由の別のケースを示しているので、これを共有したかっただけです。

@sandersn ：

それはまともな回避策を持っています-nオーバーロード

技術的には正しくありませんが、これはここでの現実を完全には反映していないと思います。 ええ、技術的にはこれがなくても、オーバーロードがこのスレッドで言及されている関数を入力するのを防ぐことはできませんでした。 それでも、この小さな不便は、これまでのところ、そのような過負荷ベースのソリューションがlib.d.tsなっていないことを意味しています。

実際、このスレッドの多くは、 ......や、 ...*X 、 [...T = ...A, ...B, ...C]など、元々この提案の一部ではなかったさらに多くの構文を提案するために、それぞれの関数に取り組むことに必死に感じています。 [...PromiseLike<T>] 、 <[...X, ...Y] = [...A]> 、および<PromiseLike<T*>> 。

これは、私たち全員がここで問題に取り組んでいることを示していると思います。このようなより強力な構文が必要であるという一般的な感覚を共有しており、ここで選択した方法が問題の解決に役立つことを願っています。

サイドノート：用RAMDAのR.path 、我々はまだ（まだ難しい順列が爆発しただろう方法）タプルのサポートを逃した過負荷の千っぽいラインの入力を生成し、ちょうど終了しないように、実際のプロジェクトでコンパイルを引き起こしましたもう。 そこに一見実行可能な代替手段として最近発見された反復（＃12290）。

ちなみに、 @ Artazorと@Igorbekが提案した提案についてはまだコメントしていません。 それについてどう思いましたか？

ここでそのような基本的な実装（および＃6606）について議論したいのですが、私たちはほぼ何でもできます。 これを説明するために、ここでいくつかの解決策を提供しますが、さらに質問をすることもできます。

まず、 ...演算子を実装

v ... for | 定義（キャプチャ）| 使用（拡散）
-|-|-
関数| type Fn = (...args: any[]) => {} | type Returns = typeof fn(...MyTuple); （＃6606）
配列| タイプレベルのタプルの破棄。 技術的には、インデックスアクセス+スプレッド（右を参照）+再帰を使用してエミュレートできます。 | type Arr = [Head, ...Tail];
オブジェクト| タイプレベルのオブジェクトの破棄。 必要ありません。 Omitを使用してください。＃12215を参照してください。 | type Obj = { a: a, ...restObj }; （不要、 Overwriteと同じ、＃12215を参照）
ジェネリック| 定義type Foo<...T>行うためにFoo<1, 2, 3> （キャプチャ[1, 2, 3 ]にT ）。 楽しいですが、どのユースケースでこれが必要かわかりません。 | 定義type Bar<A,B,C>行うBar<...[1,2,3]> （ A = 1など）。 同上、これを必要とするユースケースを知らない。
組合（ボーナス）| ？ | type Union = "a" | "b"; type MyTuple = ...Union; // ["a", "b"] （順序は信頼できませんが、タプルを介したユニオン/オブジェクトの反復が可能です。とにかく、ここでは範囲外です。）

したがって、すぐに関連するタイプレベルの...インスタンスは2つだけです。 具体的には、ここで使用される2つ：

declare function f<U, T>(head: U, ...tail: T): [U, ...T];

＃6606のコンテキストでは、別の関連性があります。関数アプリケーション用にタプル型を解凍する機能です（例： typeof f(...MyTuple) 。 私がここで言及したことを聞いたより難しい問題を解決するには、これらで十分だと思います。 ここでいくつかのソリューションを提供しようとするには：

@jameskeane ：

タプルの「要素タイプ」を表現する方法があるはずだと思います

それらの要素の和集合を取得したい場合は、私のTupleToUnion参照してください。

Promise.all

// helpers: `mapTuple` needs #5453 to define, #6606 to use
type TupleHasIndex<Arr extends any[], I extends number> = ({[K in keyof Arr]: '1' } & Array<'0'>)[I];
type Inc = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]; // longer version in gist
declare function mapTuple<F extends (v: T) => any, Tpl extends T[], T>(f: F, tpl: Tpl): MapFn<F, Tpl, T>;
type MapFn<
    F extends (v: T) => any,
    Tpl extends T[],
    T,
    // if empty tuple allowed:
    // I extends number = 0,
    // Acc = []
    // otherwise:
    I extends number = 1,
    Acc = [F(Tpl[0])]
> = { 1: MapFn<F, Tpl, T, Inc[I], [...Acc, F(Tpl[I])]>; 0: Acc; }[TupleHasIndex<Tpl, Int>];

declare module Promise {
  function all<Promises extends Promise<any>[]>(promises: Promises): typeof mapTuple(<T>(prom: Promise<T>) => T, Promises);
}

@danvk ：

_.extend

@sandersn ：

Object.assign

これらは両方とも、RamdaのmergeAllの可変個引数バージョンです。 6つのドットは必要ありません！

@isiahmeadows ：

この問題の状況について何か考えはありますか？
構文と低レベルのセマンティクスには、まだ明確なコンセンサスがありません。

私が正しく理解していれば、あなたは主に、他のいくつかが提供するアプローチが、あなたが言及したcurryやbindなどのより難しいタイピングへの取り組みを考慮に入れるかどうかを心配していました。 彼らの提案に続いて、これがその特定のものについての私の見解です。
戦略は少し似ており、関数適用への引数の型チェックを延期することによって、関数型からタプル型にparams i〜jの型要件を抽出するというのは難しいという事実をだまします。

// helpers in https://gist.github.com/tycho01/be27a32573339ead953a07010ed3b824, too many to include

// poor man's version, using a given return value rather than using `typeof` based on the given argument types:
function curry<Args extends any[], Ret>(fn: (...args: Args) => Ret): Curried<Args, Ret>;
type Curried<
  ArgsAsked,
  Ret,
  ArgsPrevious = [] // if we can't have empty tuple I guess any[] might also destructures to nothing; that might do.
> = <
  ArgsGiven extends any[] = ArgsGiven,
  ArgsAll extends [...ArgsPrevious, ...ArgsGiven]
      = [...ArgsPrevious, ...ArgsGiven]
  >(...args: ArgsGiven) =>
    If<
      TupleHasIndex<ArgsAll, TupleLastIndex<ArgsAsked>>,
      Ret,
      Curried<ArgsAsked, Ret, ArgsAll>
    >;

// robust alternative that takes into account return values dependent on input params, also needs #6606
function curry<F>(fn: F): Curried<F>;
type Curried<
  F extends (...args: ArgsAsked) => any,
  ArgsAsked extends any[] = ArgsAsked,
  ArgsPrevious = []
> = <
  ArgsGiven extends any[] = ArgsGiven,
  ArgsAll extends [...ArgsPrevious, ...ArgsGiven]
      = [...ArgsPrevious, ...ArgsGiven]
  >(...args: ArgsGiven) =>
    If<
      TupleHasIndex<ArgsAll, TupleLastIndex<ArgsAsked>>,
      F(...[...ArgsPrevious, ...ArgsGiven]),　// #6606
      Curried<ArgsAsked, Ret, ArgsAll>
    >;

// bind:
interface Function {
    bind<
        F extends (this: T, ...args: ArgsAsked) => R,
        ArgsAsked extends any[],
        R extends any,
        T,
        Args extends any[], // tie to ArgsAsked
        Left extends any[] = DifferenceTuples<ArgsAsked, Args>,
        EnsureArgsMatchAsked extends 0 = ((v: Args) => 0)(TupleFrom<ArgsAsked, TupleLength<Args>>)
        // ^ workaround to ensure we can tie `Args` to both the actual input params as well as to the desired params. it'd throw if the condition is not met.
    >(
        this: F,
        thisObject: T,
        ...args: Args
    ): (this: any, ...rest: Left) => R;
    // ^ `R` alt. to calc return type based on input (needs #6606): `F(this: T, ...[...Args, ...Left])`
}

ええ、私はたくさんのヘルパータイプを使用しました-私たちが持っているものでやり遂げようとしました（+もう少しだけで何ができるか想像してください）。 私は...... 、 ...*X 、 [...T = ...A, ...B, ...C] 、 [...PromiseLike<T>] 、 <[...X, ...Y] = [...A]> 、または<PromiseLike<T*>>にはあまり反対していません。 しかし、IMOは、たったの...でも、今のところ実際の問題に対処するのに役立ちます。私はそれが解決されることを望んでいます。

編集： bindの引数の制約を解決しました。

おそらくばかげた質問です。 これは、カレー関数を正しく入力できることは非常に有望に見えます。
しかし、実際のプロジェクトの中には、関数型プログラミング指向のコードを入力するのに多くの時間を費やしたくないものもあります。
したがって、 --strictは_tsconfig.json_でデフォルトで有効になっているので、コードの一部の型チェックを無効にする方法があるかどうか疑問に思っています（怠惰または時間の不足のため）。
しかし、私が言ったように、それはおそらく愚かな質問です... ^ _ ^

@ yahiko00はちょっとオフトピックですが、 tsconfig excludeセクション、または異なるプロジェクトレベルの異なるtsconfigます。

また、別の提案をしたいと思います。 &と|が、次の構文の単一のタプル引数で機能するようにすることができますか。

<...T>(...args:T): ...T&
// is the same as 
<t1, t2, t3>(...args:[t1, t2, t3]): t1 & t2 & t3;
// and
<....T>(...args:T): ...T|
// is the same as 
<t1, t2, t3>(...args:[t1, t2, t3]): t1 | t2 | t3;

@HyphnKnightの上記の提案は、私がやっていることにも非常に役立ちます。

この提案は積極的に取り組んでいないという免責事項を追加したいと思います。 しかし、私がこの問題を最初に見始めたときに読みたかった「先行技術」の種類の紙を正確に見つけました： http ：

後で参照できるように、ここに残しておきます。

私はこれに向けて実験しているいくつかのPRを開きました：

• []＃17884タプルタイプのスプレッド（WIP）
• [x]＃17898残りのパラメータを抽出（準備完了）
• []＃18007タイプコール（WIP）で拡散

const c = 'a' + 'b';

問題を解決できますか？ c推論タイプは'ab'ではなくstring

StackOverflowに関連する質問： TypeScriptの明示的な最後の関数パラメーター

@sandersnあなたの提案は、私が見る限り、このケースをカバーするでしょう、これは正しいですか？

最初の提案から2年以上経っても、私たちはまだ希望を持ち続けるべきでしょうか？

こんにちは！
可変数の配列を受け取り、それらの要素を組み合わせて新しい配列を作成するジェネレーターを入力しようとしています。
このジェネレーターをfor...ofループで使用したいのですが、値を正しく入力できません。
コード（まだ実行していないので間違いがあるかもしれませんが、これが私がやろうとしていることです）：

function* CombineEveryArgumentWithEveryArgument(...args: any[][]) {
    if (args.length < 1) {
        return [];
    }
    var haselements = false;
    for (var arg of args) {
        if (arg && arg.length > 0) {
            haselements;
        }
    }
    if (!haselements) {
        return [];
    }
    var indexes = [];
    for (var i = 0; i < args.length; i++) {
        indexes.push(0);
    }
    while (true) {
        var values = [];
        //One item from every argument.
        for (var i = 0; i < args.length; i++) {
            values.push(args[i][indexes[i]]);
        }
        if (indexes[0] + 1 < args[0].length) {
            yield values;
        }
        else {
            return values;
        }
        //Increment starting from the last, until we get to the first.
        for (var i = args.length; i > 0; --i) {
            if (indexes[i]++ >= args[i].length) {
                indexes[i] = 0;
            }
            else {
                break;
            }
        }
    }
}

使用例：

for (let [target, child] of
    CombineEveryArgumentWithEveryArgument(targetsarray, childrenarray)) {

中間変数を作成せずに、ターゲットと子の入力を取得する方法を理解することはできません。

このようなものがいいでしょうか？

function * generator<...T[]>(...args: T[]): [...T]

@Griffork正しい方法は、この提案が実装されるまで、関数に多くのオーバーロードを作成することです。
たとえば、promise.allタイプを参照してください
https://github.com/Microsoft/TypeScript/blob/master/lib/lib.es2015.promise.d.ts#L41 -L113

この構文は非常に紛らわしいと思います。

function apply<...T,U>(ap: (...args:...T) => U, args: ...T): U {

これは私にとってはるかに自然に感じます：

function apply<T, U>(ap: (...args: T) => U, args: T): U {

実行時のRESTパラメーターは配列であり、現在TSでこれを行うことができます。

function apply<T, U>(ap: (...args: T[]) => U, args: T[]): U {

したがって、 argsがT配列であるという制限を取り除き、代わりにTSコンパイラがTタプル型を推測できるようにするのは論理的であるように思われます。

function apply(ap: (...args: [number, number]) => number, args: [number, number]): number {

タプルについていくつかの懸念が提起されており、すべてを完全に理解しているわけではありませんが、現在の提案では、開発者がいつ...を使用する必要があるかを理解するのが難しいことを考慮したかっただけです。タイプの位置にあり、タプルははるかに直感的です。

...は、 [...T, ...U]ように、2つのタプルタイプを連結することには意味があります。

@felixfbecker
の提案

function apply<...T,U>(ap: (...args:T) => U, ...args: T): U {

Tは動的に作成されたタプル型であるため、 stringとintを関数に渡すと、 Tは[string, int] 。
これは、次のようなパターンを動的に表現したい場合に特に興味深いものです。

function PickArguments<T>(a: T[]): [T];
function PickArguments<T, U>(a: T[], b: U[]): [T, U];
function PickArguments<T, U, V>(a: T[], b: U[], c: V[]): [T, U, V];
//More overloads for increasing numbers of parameters.

//usage:
var [a, b, c] = PickArguments(["first", "second", "third"], [1, 2, 3], [new Date()]);
var d = b + 1; //b and d are numbers.
var e = c.toDateString(); //c is a date (autocompletes and everything), e is a string.

現時点では、可変数の引数を取り、それらを一般的に入力する関数を作成する場合は、関数に指定できる可能性のある引数の数ごとに、一般化されたオーバーロードを作成する必要があります。 ...T提案により、基本的に、コンパイラーに関数定義を自動的に生成させることができます。

あなたの提案：

function apply<T, U>(ap: (...args: T) => U, args: T): U {

すべてのパラメーターが同じタイプとして扱われるように強制し、より具体的なタイプチェックを行うことはできません。 たとえば、上記の例では、すべての戻り値はanyます。

また、余分な...は非常に読みにくいと思います。
@felixfbeckerのアイデアのように、私はする必要がないと思います：

function apply<...T, U>(ap: (...args: ...T) => U, args: ...T): U {...}

apply<...T,読むときに最初に頭に浮かぶのは、それが拡散演算子であるということですが、実際には拡散はまったく行いません。

@Griffork 、あなたの例では、 Tはまだ[string, int]ます。
これが、 @ felixfbeckerが「TSコンパイラがTのタプル型を推測できるようにする代わりに」、少なくとも私が理解している方法で意味することです。

すべてのパラメーターが同じタイプとして扱われるように強制し、より具体的なタイプチェックを行うことはできません。 たとえば、上記の私の例では、すべての戻り値はany型になります。

@Grifforkいいえ、私の考えでは、 args配列のタプル型を推測し、タプル内の位置によって各パラメーターに独自の型を与えます。 ...args: T[]は、それらすべてを同じ型Tに強制しますが、 ...args: T （現在はコンパイルエラーです）はTタプル型を推測します。

apply <... Tを読むときに最初に頭に浮かぶのは、それが拡散演算子であるということですが、実際には拡散はまったく行いません。

@unionalは同意します、それはまさに混乱が生じるところです。

@unional
私もスプレッド演算子として読み、「使用するたびにこのタイプをスプレッドする」と読みました。
私にとって、これを読んで

function apply<T, U>(ap: (...args: T) => U, args: T): U {

Tは何かの配列（たとえばstring[] ）であると思います。

そしてこれを読んで：

function apply<T, U>(ap: (...args: T[]) => U, args: T[]): U {

すべての引数がタイプT （ stringなどの1つのタイプ）に割り当て可能であると思います。

上記の提案のポイントは、ジェネリックスが任意の数の型を表現できるようにすることを暗黙的に回避することでした。

@felixfbecker
編集：
ああ、わかりました。 それでも、それが直感的だとは思わないでください。

Tは何かの配列（たとえばstring []）であると思います。

タプルは「何かの配列」であり、固定長で各要素の特定の型を持つ単なる配列です。たとえば、 [string, number] （vs (string | number)[] 、これはバインドされておらず、どの要素に何があるかを宣言しません）タイプ）。

では、実際にその動作が必要な場合は、何を入力しますか？

正確にどのような動作を参照しているかはわかりませんが、「すべてのパラメーターを同じタイプにする」と想定しています。これは、 ...args: T[]によって実現されます。

私もスプレッド演算子として読み、「使用するたびにこのタイプをスプレッドする」と読みました。

だから混乱していると思います。
拡散するときは、それを実行するだけで、「拡散可能」なものを宣言することはありません。

const a = { x: 1, y: 2 }
const b = { ...a }

// likewise
function appendString<T>(...args: T): [...T, string] {
  args.push('abc')
  return args
}

うん。 ジェネリック型引数が「読み取り可能」である必要があることを宣言したい場合（ES仕様では、反復可能でなければならないことを意味します）、TypeScriptでextendsしてそれを表現する方法がすでにあります。

function foo<T extends Iterable<any>>(spreadable: T): [...T, string] {
  return [...spreadable, 'abc']
}

const bar = foo([1, true])
// bar is [number, boolean, string]

もちろん、RESTパラメーターの場合、それはIterableだけでなく、配列であることが知られています。

これは、私たちが言っていることはすでに提案されています： https ：

しかし、残りは1つの座席で消費するには長すぎます。 🌷

タプル連結が着陸している場合は、教会番号を実装できます！ やったー！

type TupleSuc<T extends [...number]> = [...T, T['length']];
type TupleZero = [];  // as proposed, we need empty tuple
type TupleOne = TupleSuc<TupleZero>;
type Zero = TupleZero['length'];
type One = TupleOne['length'];

また、条件型の再帰が機能している場合は、必要な長さのタプルを作成できます。

type Tuple<N extends number, T = TupleZero> = T['length'] extends N ? T : Tuple<N, TupleSuc<T>>;
type TupleTen = Tuple<10>;
type Ten = TupleTen['length'];

このスレッドをすべて読んだとは思いませんが、ジェネリックパラメーターに...Tれていると混乱する場合は、
値レベルの破壊構文をさらにミラーリングして、 [...T]を使用するようにしてみませんか。
タイプレベルの引数の位置は、タイプレベルのタプルの場合、タイプを非構造化しますか？ これも必要になります
タプルを使用してRESTパラメーターを入力できるようにします。これにより、呼び出しサイトで次のようになります。
TypeScriptの場合：

const first = (a: number, b: string) => …;
const second = (...ab: [number, string]) => …;

first(12, "hello"); // ok
second(12, "hello"); // also ok

INB4「しかしそれはタイプ指向の放出です」–いいえ。 これは何も変更せず、 firstまだ2つあります
個別の引数が発行されても、 secondはまだ1つのREST引数があります。 変更されるのは
呼び出しサイトで、TypeScriptはsecondのパラメーターがタプルと順番に一致することを確認します。
[number, string] 。

とにかく、 [...Type]構文を認めると仮定すると、次のようにapplyと書くことができます。

function apply<
  [...ArgumentsT], // a type-level tuple of arguments
  ResultT
>(
  // the call site of `toApply` function will be used to infer values of `ArgumentsT`
  toApply:   (...arguments: ArgumentsT) => ResultT,
  arguments: ArgumentsT
) :
  ResultT
{
  // …
}

// NB: using my preferred formatting for complex type-level stuff; hope it's readable for you
// this is entirely equivalent to OP's notation version:
function apply<[...T], U>(ap: (...args: T) => U,  args: T): U {
  // …
}

// so at the call site of
const fn = (a: number, b: string, c: RegExp) => …;

// we have `ArgumentsT` equal to [number, string, RegExp]
apply(fn, [12, "hello" /s+/]); // ok, matches `ArgumentsT`
apply(fn, [12, /s+/]); // not ok, doesn't match `ArgumentsT`

[...Type]構文は完全に値レベルの破壊として動作し、分割が可能になります
必要に応じて、タイプレベルのタプルを結合します。

type SomeType  = [string, number, "constant"];
type OtherType = ["another-constant", number];

type First<[First, ..._]> = FirstT;
type Rest<[_, ...RestT]> = RestT;
type Concat<[...LeftT], [...RightT]> = [...LeftT, ...RightT];
type FirstTwo<[FirstT, SecondT, ..._]> = [FirstT, SecondT];

// has type `string`
const aString: First<SomeType> =
  "strrriiing";
// has type `[number, "constant"]
const numberAndConstant: Rest<SomeType> =
  [42, "constant"];
// has type `[string, number, "constant", "another-constant", number]`
const everything: Concat<SomeType, OtherType> =
  ["herpderp", 42, "constant", "another-constant", 1337];
// has type `[string, number]`
const firstTwo: FirstTwo<SomeType> =
  ["striiiing", 42];

これを使用してcurry関数を入力する方法の例：

type Curried<
  [...ArgumentsT]
  ResultT,
  ArgumentT      = First<ArgumentsT>,
  RestArgumentsT = Rest<ArgumentsT>
> =
  // just ye olde recursione, to build nested functions until we run out of arguments
  RestArgumentsT extends []
    ? (argument: ArgumentT) => ResultT
    : (argument: ArgumentT) => Curried<RestArgumentsT, ResultT>;

// NB. with more complex generic types I usually use generic defaults as a sort-of
// of type-level variable assignment; not at all required for this, just nicer to read IMO

function curry<
  [...ArgumentsT],
  ResultT
>(
  function: (...arguments: ArgumentsT) => ResultT
) :
  Curried<ArgumentsT, ResultT>
{
  // do the magic curry thing here
}

// or in the short indecipherable variable name style

function curry<[...T], U>(fn: (...args: T) => U): Curried<T, U>
{
  // …
}

// this should let you do this (using `fn` from before)
const justAddRegex = curry(fn)(123, "hello");

justAddRegex(/s+/); // ok, matches the arguments of `fn`
justAddRegex(123); // not ok, doesn't match the arguments of `fn`

一部の型引数は型レベルのタプルであると言えることも役立つと思います。
ある種の。 問題は、2.7（私は思う？）以降のタプルの割り当て可能性がどのようにかかるかということです。
タプルの長さを考慮に入れる–_任意のタイプレベルのタプル_の概念を表現します。 しかし多分何かのような
[...]は機能しますか？ 強い意見はありませんが、コンセプトに名前を付けていただければと思います。

// bikeshed me
type OnlyTuplesWelcome<ArgumentT extends [...]> = ArgumentT;

その場合、上記の[...ArgsT]構文は、基本的にArgsT extends [...]省略形になります。
タイプレベルのデストラクチャリングを使用するということは、タイプがタイプレベルのタプルになるという制約を意味します。

考え？

@jaen ：

(...ab: [number, string]) => …

ええ、それは＃4130のように見えます。 ＃18004で何かを試しましたが、私のアプローチは少しハッキーでした（合成ノード）。

タプルを表現する際に、誰かがany[] & { 0: any }を使用しているのを見たことがあります。これは、空のタプルタイプfwiwまで機能すると思います。 私は個人的にはあまり気にしませんでしたが、ほとんどはany[] 。

RxJSはこれをあちこちで必要としています。 最も重要なのはObservable.prototype.pipe 、現在多くのオーバーロードがありますが、常に「もう1つのレベル」を追加するように求められます。

2番目の@benleshでは、RXJSを広範囲に使用しており、パイプ関数にこれが必要です。

私はppipeの作者です。これは、RXJSのパイプ関数と同様に、これを必要とします。 ここに模様が見えると思います^^

私はruntypesの作成者で和集合と共通部分を表現するために切実に必要とされています。 唯一の（不完全な）回避策は、巨大な過負荷です。

https://github.com/pelotom/runtypes/blob/master/src/types/union.ts

🤢

ラムダの種類を書き直しました。これもpipe 、レンズ、カリー化などに必要です。
カリー化によって過負荷を直接維持することが管理できなくなったため、codegenが必要でした。 pathタイプは1000行を超えていましたが、その時点でオーバーロードタイプのパフォーマンスも問題になっていることがわかりました。

REST引数の推測と適用に関する問題は解決されましたか？

function example(head: string, ...tail: number[]): number[] {
  return [Number(head), ...tail]
}

function apply<T, U>(fn: (...args: T) => U, args: T): U {
  return fn.apply(null, args)
}

中にTのタイプの場合はapply(example, ['0', 1, 2, 3])と推察される[string, number[]] 、適用する呼び出しがエラーを発生させるでしょう。

つまり、Tのタイプは本当に

type T = [string, ...number[]]

また

type T =
  {0: string} &
  {[key: Exclude<number, 0>]: number} &
  Methods

確かに奇妙な獣ですが、 ({0: string} & Array<number>)[0]がどのようになるかを考えると
現在string解決されています[1]あまり変更せずにエンコードできるようです
型システムに。

[1]これはバグですか、本当にstring | numberますか？

この問題の36人の参加者に迷惑をかけて申し訳ありませんが（ヒント：これを使用し

2年半経ってもまだ誰も割り当てられていないのは悲しいことですが、かなり重要な機能のようです:(

PS：数十のコメントを読んだり、Cmd + Fなどを試したりしましたが、この情報は見つかりませんでした。

@brunolemos最新の設計会議で可変個引数タイプへの参照があります
https://github.com/Microsoft/TypeScript/issues/23045
この機能を作成するには、最初に、より原始的で概念を繰り返し作成する必要があります。十分な基盤がある場合は、マイルストーンに追加すると確信しています。

私はなんとか機能するbindを実装することができました

これは私にはできない

type Last<T extends any[]> =
    T extends [infer P] ? P :
    ((...x: T) => any) extends ((x: any, ...xs: infer XS) => any) ? Last<XS> :

＃14174の問題ですが、関係として

参照用の@kgtkrは、コンパイラに再帰を見逃させるための@fightingcatのトリックを参照してください。

ありがとう

type Last<T extends any[]> = {
    0: never,
    1: Head<T>,
    2: Last<Tail<T>>,
}[T extends [] ? 0 : T extends [any] ? 1 : 2];

うーん、質問があります。 ミックスインを処理するための次のようなコードがあります。

export const Mixed = <

    OP = {}, OS = {}, // base props and state
    AP = {}, AS = {}, // mixin A props and state
    BP = {}, BS = {}, // mixin B props and state
    // ...and other autogenerated stuff
>(

    // TODO: Find a way to write that as ...args with generics:
    a?: ComponentClass<AP, AS>,
    b?: ComponentClass<BP, BS>,
    // ...and other autogenerated stuff

) => {

    type P = OP & AP & BP;
    type S = OS & AS & BS;
    const mixins = [a, b];

    return class extends Component<P, S> {
        constructor(props: P) {
            super(props);
            mixins.map(mix => {
                if (mix) {
                    mix.prototype.constructor.call(this);
                    // some state magic...
                }
            });
        }
    };
};

私はそれを次のように使用します：

class SomeComponent extends Mixed(MixinRedux, MixinRouter, MixinForm) {
     // do some stuff with mixed state
}

適切なタイピング、状態処理などで期待どおりに機能しますが、可変個引数の種類を待たずに、より短い方法で書き直す方法はありますか？ 私は今これについて少し馬鹿げていると感じているからです。

3.0では、restargsをtuppleとして宣言できるようになりました。

declare function foo(...args: [number, string, boolean]): void;

しかし、逆に取得して、指定された関数のタプル型の引数を取得することは可能ですか？

Arguments<foo>ようなものがいいでしょう。

@whitecolorこれはどうですか？

type Arguments<F extends (...x: any[]) => any> =
  F extends (...x: infer A) => any ? A : never;

TS 3.0では、これを今すぐ実行できます

function compose<X extends any[], Y extends any[], Z extends any[]>(
  f: (...args: X) => Y,
  g: (...args: Y) => Z
): (...args: X) => Z {
  return function (...args) {
    const y = f(...args);
    return g(...y);
  };
}

しかし、単一のパラメータに対してタプルイベントを返す関数を宣言し、なんらかの方法でvoidを処理する必要があるという小さな問題があります。それ以外の場合は、配列として推測される戻り型を宣言する必要があります:)

https://www.typescriptlang.org/play/index.html#src =％0D％0A％0D％0A％0D％0A％0D％0A％0D％0A％0D％0A％0D％0Afunction％20foo0（） ％3A％20void％20％7B％0D％0A％20％0D％0A％7D％0D％0A％0D％0Afunction％20bar0（）％3A％20void％20％7B％0D％0A％0D％0A％7D ％0D％0A％0D％0Afunction％20foo1（a％3A％20string）％3A％20％5Bstring％5D％20％7B％0D％0A％20％20return％20％5Ba％5D％3B％0D％0A％ 7D％0D％0A％0D％0Afunction％20bar1（a％3A％20string）％3A％20％5Bstring％5D％20％7B％0D％0A％20％20return％20％5Ba％5D％3B％0D％0A ％7D％0D％0A％0D％0Afunction％20foo2（a1％3A％20string％2C％20a2％3A％20boolean）％3A％20％5Bstring％2C％20boolean％5D％20％7B％0D％0A％20％ 20return％20％5Ba1％2C％20a2％5D％3B％0D％0A％7D％0D％0A％0D％0Afunction％20foo21（a1％3A％20string％2C％20a2％3A％20boolean）％3A％20％5Bstring ％5D％20％7B％0D％0A％20％20return％20％5Ba1％5D％3B％0D％0A％7D％0D％0A％0D％0A％0D％0Afunction％20bar2（a1％3A％20string％2C ％20a2％3A％20boolean）％3A％20％5Bstring％2C％20boolean％5D％20％7B％0D％0A％20％20return％20％5Ba1％2C％20a2％5D％3B％0D％0A％7D％ 0D％0A％0D％0A％0D％0Afunction％20compose％3CX％20extends％20any％5B％5D％2C％20Y％20extends％20any％5B％5D％2C％20Z％20extends％20any％5B％5D％3E（ ％0D％0A％20％20f％3A％20（..。 args％3A％20X）％20％3D％3E％20Y％2C％0D％0A％20％20g％3A％20（... args％3A％20Y）％20％3D％3E％20Z％0D％0A ）％3A％20（... args％3A％20X）％20％3D％3E％20Z％20％7B％0D％0A％20％20return％20function％20（... args）％20％7B％ 0D％0A％20％20％20％20const％20y％20％3D％20f（... args）％3B％0D％0A％20％20％20％20return％20g（... y）％3B％ 0D％0A％20％20％7D％3B％0D％0A％7D％0D％0A％0D％0A％0D％0A％0D％0A％0D％0Aconst％20baz0％20％3D％20compose（％0D％0A ％20％20foo0％2C％0D％0A％20％20bar0％0D％0A）％3B％0D％0A％0D％0Aconst％20baz21％20％3D％20compose（％0D％0A％20％20foo21％2C％0D ％0A％20％20bar1％0D％0A）％3B％0D％0Aconst％20baz2％20％3D％20compose（％0D％0A％20％20foo2％2C％0D％0A％20％20bar2％0D％0A）％ 3B％0D％0A％0D％0A％0D％0Aalert（baz2（ 'a'％2C％20false））％0D％0Aalert（baz21（ 'a'％2C％20true））％0D％0Aalert（baz0（））

@maciejw
条件付きタイプを使用します。

function compose<X extends any[], Y extends any, Z extends any>(
  f: (...args: X) => Y,
  g: Y extends any[] ? (...args: Y) => Z : () => Z
): (...args: X) => Z {
    return function (...args) {
        const y = (f as any)(...args);
        return (g as any)(...y);
    } as any;
}

確かに、しかしこれはそれらのas any一種のハッキーです:)型システムがハックなしでこれをサポートしたならそれはクールだと思います

ええと、関数本体の型は複数のものである可能性があり、それについてできることはあまりありません。代わりに(f as (...args: any[]) => Y)ようなことをすることができますが、それは本当の理由もなく明快さを減らすと思います

可変個引数型が実を結ぶと、自分のプロジェクト用に作成したTypeScriptコードを一般化して、REST APIの形状を完全に定義し、対応するノードサーバーとJavaScriptの型にその形状を適用できるようになります。そのためのクライアントライブラリ。

これを一般化すると、自分のコードを単純化できるほか、任意のAPIに対して同じことを実行できます。さらに進んで、他の言語のクライアント用にSwagger定義を生成することもできます...他の人にも役立つ可能性があります。 はははでも声を出して夢を見ている

パイプの入力に成功しました
https://github.com/kgtkr/typepark/blob/master/src/pipe.ts

@kgtkr ：それは素晴らしいですね！ :)

パイプタイプは私にとってTSプレイグラウンドをクラッシュさせます（他の人はうまく機能しますが）、私はそれが最新のTSを必要としていると思いますか？

TSは、いくつかの再帰深度エラーも示しています- @ isiahmeadowsがそのために＃26980を開いたようです。

@ tycho01

パイプタイプは私にとってTSプレイグラウンドをクラッシュさせます（他の人はうまく機能しますが）、私はそれが最新のTSを必要としていると思いますか？

それは私にとってもハングします、そして私はそれを抜け出すためにそれがエラーを投げるように強制するためにdevtoolsにハックしなければなりませんでした。

TSは、いくつかの再帰深度エラーも示しています- @ isiahmeadowsがそのために＃26980を開いたようです。

これは関連するものですが、異なるものです。2つの理由から、条件付き型で制約を解除します。

• リストの反復など、より複雑な作業を簡単に行えるようにするため。 また、コンパイラをクラッシュさせたり、アドホックな混乱を引き起こしたりすることなく、型レベルの整数演算などを開くためのフレームワークを構築します。
• TSの型システムをチューリング完全にする原因の問題にさらに適切に対処するために、それを活用するツールで修正するか、将来的に証明可能な終了を強制することで削除できる可能性があります。

インデックス付きの型を削除するだけでは、型システムをチューリング完全ではない状態にするのに十分でない場合は、コメントをドロップして、それに応じて更新できるようにしてください。 （もちろん、それを削除することは提案しません。潜在的な無限ループについて人々に警告するために、内部でより適切に処理することを提案します。）

考え直してみると、このパイプタイプは、 (vs...: Params<T[0]>) => ReturnType<Last<T>>を実行するための非常に複雑な方法のように感じます。 それを超える反復（中間パラメーターチェックを除く）は、入力に依存する戻りタイプでおそらくより有用になります。

@ tycho01次のようなものを入力しようとしています。ここで、タイプは基本的に次のとおりです。

   f1,     f2,   ...,   fm,     fn    -> composed
(a -> b, b -> c, ..., x -> y, y -> z) -> (a -> z)

後続のパラメータ戻り値パラメータは、前のパラメータに依存しているので、あなたは、それを正しく入力するために、個別のパラメータを反復する必要があります。また、（「sがない@kgtkr）最初のパラメータと終了の戻り値を考慮するために持っています。 ＃26980の「改善された」バージョンでは、代わりにアキュムレータを使用するように最適化されたため、引数の反復回数は大幅に減りましたが、より正確になりました。

＃26980で私のものを見ると、それが何をしているのかが少し明確になっています（数の追跡が少ない）。それが、私がその機能要求を提出した理由の一部です。

@ tycho01 @kgtkrところで、私はそのバグを修正されたPipeFuncスニペットで更新しました。便宜上、ここにコピーしました。

type Last<L extends any[], D = never> = {
    0: D,
    1: L extends [infer H] ? H : never,
    2: ((...l: L) => any) extends ((h: any, ...t: infer T) => any) ? Last<T> : D,
}[L extends [] ? 0 : L extends [any] ? 1 : 2];

type Append<T extends any[], H> =
    ((h: H, ...t: T) => any) extends ((...l: infer L) => any) ? L : never;

type Reverse<L extends any[], R extends any[] = []> = {
    0: R,
    1: ((...l: L) => any) extends ((h: infer H, ...t: infer T) => any) ?
        Reverse<T, Append<R, H>> :
        never,
}[L extends [any, ...any[]] ? 1 : 0];

type Compose<L extends any[], V, R extends any[] = []> = {
    0: R,
    1: ((...l: L) => any) extends ((a: infer H, ...t: infer T) => any) ?
        Compose<T, H, Append<R, (x: V) => H>>
        : never,
}[L extends [any, ...any[]] ? 1 : 0];

export type PipeFunc<T extends any[], V> =
    (...f: Reverse<Compose<T, V>>) => ((x: V) => Last<T, V>);

ところで、これは遊び場でクラッシュしません。 実際にタイプチェックを行い、非常に迅速に実行します。

潜在的な_.flowまたは_.flowRightタイプでまだテストしていませんが、それは出発点として機能するはずです。

@ tycho01
必要
typescript @ next
3.0.1 /3.0.2が機能しない

このスレッドのおかげで、私はこれを作り

皆さん、この問題の議論にほとんど関係のない情報の投稿をやめてください。 可変個引数の種類が必要なため、このディスカッションをフォローしている人はたくさんいます。 この問題をフォローしている理由とは関係のない、過去2日間に10通以上のメールを受け取りました。
私に同意する人が他にいると思います。 これまでは、スパムに貢献したくなかったので、停止することを望んでいました。 しかし、真剣に、十分です。
PSこの通知をお詫びします、私と同じくらい彼らにうんざりしている人には

@Yuudaari Lodashの_.flow 、Ramdaの_.composeなどを入力することが、このバグの原動力の1つであり、入力を成功させることは、この問題の解決の一部であることを指摘します。 実際、これが元の問題の説明に記載されている理由の1つです。

実際、現時点では、可変個引数で今日存在する問題の99％は、機能ではなく人間工学にあると私は考えています。 私たちは、入力することができますFunction.prototype.bindとPromise.allあなたは繰り返し行うことができ、インデックス付きのタイプの混合物と完全に、条件付きのタイプ、および再帰（ Appendのためのリスト反復Function.prototype.bind 、およびPromise.allは単純な反復+ Append ）になりますが、そうするのは非常に厄介で定型的です。

始まったばかりのものと説明し、ノイズここに追加しようとしていないここでは、それは彼らがものでない場合でも、あなたが個人的に心配している、バグが存在する理由の一部に関係するように、話題は技術的です。

ここで発表を待っている人々は大きなニュースを見逃したと思います-今や可能になったConcat<T, U>は[...T, ...U]まったく同じように機能することが

Pipeサブスレッドは、ここで要求した機能のデモンストレーションに関するものです。 今日、このスレッドのポイントに到達することについてです。

これは、このスレッドを閉じても悪くないことを意味すると思うので、おそらくこれは質問する良い機会です-人々はまだこの提案に何を望んでいますか？

[それは]それは非常に厄介で定型的です

これを使用するほとんどの型は再帰自体を使用するため、それらを作成する人は間違いなくそれらに精通していますが、エンドユーザーはTSの反復が存在することを知らなくても、事前定義された型のライブラリを使用してフロントエンドを作成する可能性があります。

その時点で、おそらくこの提案は主にパフォーマンスを改善する可能性がありますか？

まず、マップオブジェクトを使用して、型システムをだまして、意図したとおりに再帰を実行させていますか？ それは私にはかなりハッキーのようです。 私がそのような機能を使用する場合（私はそうですが、それは無関係です）、後で壊れることはありませんか？

第二に、これらの回避策を使用することは...友好的ではありません。 それはあまり読みにくく（特にそれを書かなかった人にとって）、その結果、維持するのは惨めに見えます。

回避策があるという理由だけで、意図された、読みやすく、保守可能な方法で同じ機能を追加する提案に頼りたいのはなぜですか？

この回避策の存在がこの提案をシンタックスシュガーと見なす原因にはならないと思いますが、たとえそうだったとしても、なぜこの混乱にシンタックスシュガーが必要ないのでしょうか。

@Yuudaari

編集：コンテキストのリンクを追加します。

まず、マップオブジェクトを使用して、型システムをだまして、意図したとおりに再帰を実行させていますか？ それは私にはかなりハッキーのようです。 私がそのような機能を使用する場合（私はそうですが、それは無関係です）、後で壊れることはありませんか？

私が最近提出したバグを見てください：＃26980。 パターンを疑問視しているのはあなただけではありません。 ここでは少し話題から外れていますが、気軽にチャイムを鳴らしてください。

再帰的なものが終了するかどうかを判断する方法には、少し数学が関係していることに注意してください（そもそもそれが非常に微妙な違いがある主な理由の1つ）。

第二に、これらの回避策を使用することは...友好的ではありません。 それはあまり読みにくく（特にそれを書かなかった人にとって）、その結果、維持するのは惨めに見えます。

回避策があるという理由だけで、意図された、読みやすく、保守可能な方法で同じ機能を追加する提案に頼りたいのはなぜですか？

この回避策の存在がこの提案をシンタックスシュガーと見なす原因にはならないと思いますが、たとえそうだったとしても、なぜこの混乱のためにシンタックスシュガーを望まないのでしょうか？

事実上Array.prototype.mapであるという一般的なケースでタプルを反復する単純化された方法は存在しますが、それは基本的に私のニーズには役に立ちませんでした（アキュムレータが必要でした）。

私は個人的にこれらのシンタックスシュガーが欲しいです：

1. [...First, ...Second]を介して2つのリストを連結します。
2. [...Values, Item]を介して値を追加します。
3. T extends [...any[], infer Last]介して最後の要素を抽出します。
4. T extends [A, B, ...infer Tail]を介してテールを抽出します。

それを＃26980と組み合わせると、上記のタイプを次の

type Compose<L extends any[], V, R extends any[] = []> =
    L extends [infer H, ...infer T] ?
        Compose<T, H, [...R, (x: V) => H]> :
        R;

export type PipeFunc<T extends any[], V> =
    T extends [...any[], infer R] ?
        (...f: Compose<T, V>) => ((x: V) => R) :
        () => (x: V) => V;

しかし、それはそれについてです。 ここではほとんどすべてがタプルを扱っているだけであり、オブジェクトにはすでに同様の操作に必要なものがすべて含まれているため、他のシンタックスシュガーの使用はあまり見られません。

まず、マップオブジェクトを使用して、型システムをだまして、意図したとおりに再帰を実行させていますか？ それは私にはかなりハッキーのようです。 私がそのような機能を使用する場合（私はそうですが、それは無関係です）、後で壊れることはありませんか？

公式の言葉は「やらないで」みたいなものだと思います。 @ahejlsbergは言った：

それは賢いです、しかしそれは確かにそれらの意図された使用をはるかに超えて物事を押し進めます。 小さな例では機能するかもしれませんが、ひどくスケーリングします。 これらの深く再帰的な型を解決するには、多くの時間とリソースが消費され、将来、チェッカーにある再帰ガバナーに反する可能性があります。

しないでください！

☹️

@jcalzでは、＃26980が存在する理由はさらに多いのでしょうか。

今年の終わりにTSを使い始めたとき、私の傾向は_ちょうどそれ_を書くことでした！ （ ...T ）可変個引数typevarタプルの構文になることを期待して。 まあ、これが入ることを願っています:)

[...T, ...U]新しい使用法を見つけました：HTMLビルダーを正しく入力します。 具体的な例として、 <video>の子は次のようになっている必要があります。

• 要素にsrc属性がある場合：
  
  
  
  • 0個以上の<track>要素
  
  
• 要素にsrc属性がない場合：
  
  
  
  • 0個以上の<source>要素
  
  
• audioまたはvideo子孫要素が許可されていないことを除いて、親のコンテンツモデルに従って0個以上の要素。

これは基本的にこのタイプと同じですが、今日TypeScriptでこれを表現する方法はありません。

type VideoChildren<ParentModel extends string[]> = [
    ...Array<"track">, // Not possible
    ...{[I in keyof ParentModel]: P[I] extends "audio" | "video" ? never : P[I]},
]

3。5年：/

使用事例：

type DrawOp<...T> = (G: CanvasRenderingContext2D, frame: Bounds, ...args: any[]) => void;
const drawOps: DrawOp<...any>[] = [];

function addDrawOp<...T>(fn: DrawOp<...T>, ...args: T) {
    drawOps.push(fn);
}

提案の未解決の質問のセクションで簡単に言及されている過負荷が表示されるだけですが、間違いなく私が遭遇したものであり、解決策や提案を見るのに最適です。例：

  function $findOne(
    ctx: ICtx,
    filter: FilterQuery<TSchema>,
    cb: Cb<TSchema>,
  ): void;
  function $findOne<T extends keyof TSchema>(
    ctx: ICtx,
    filter: FilterQuery<TSchema>,
    projection: Projection<T>,
    cb: Cb<Pick<TSchema, T>>,
  ): void;
  function $findOne(
    ctx: ICtx,
    filter: FilterQuery<TSchema>,
    projection: undefined,
    cb: Cb<TSchema>,
  ): void;
  function $findOne<T extends keyof TSchema>(
    ctx: ICtx,
    filter: mongodb.FilterQuery<TSchema>,
    projection: Projection<T> | Cb<TSchema> | undefined,
    cb?: Cb<Pick<TSchema, T>>,
  ): void {

  promisify($findOne) // this can't infer types correctly

現在、これはまったく機能せず、 promisifyを(ctx: ICtx, filter: FilterQuery<TSchema>) => Promise<TSchema[]>と入力するだけで、これらの署名から情報が失われます。

AFAICTこれに対する唯一の実際の解決策は、基本的に、promise関数を作成し、そのバリアントにすべての可能なタイプを手動で指定することです-ラップされたバリアントから名誉ある署名を実際に提供する唯一の方法は、オーバーロードを指定せず、実装署名を指定することです。ただし、そのようにシグニチャを指定した場合、渡す引数に基づいて、どのリターンタイプを期待する必要があるかを呼び出し元に知らせる方法はありません。

これは、残りのパラメーターが最後のパラメーターにしかなり得ないという事実によって悪化します（つまり、 (cb, ...args)は有効ですが、 (...args, cb)は有効ではないため、署名が内部的に共用体型であっても、実際にはできません。物事を正しく広める-たとえば、 cbが常にfunction promisify<T, V extends any[]>(fn: (cb: (err: Error | null, res?: T) => void, ...args: V)): (...args: V) => Tとしてpromisifyと入力する最初の引数であり、少なくとも同じ戻り応答を持つ署名の共用体型を取得できる場合は、かなり簡単ですが、これが最後のパラメータであり、ここで実行できることはあまりありません。

@ Qix-シナリオは＃24897によって有効になります。 TS3.0で実装されました。

@ahejlsberg Oof！ 素晴らしい、ありがとう♥️

長い間待っていました...しかし、今日は可変個引数の種類を書くことができます。 TSは、機能する複雑な型を作成するのに十分成熟しています。 そこで、ラムダのカレー、コンキャット、コンポジション、パイプのタイプを書くのに時間をかけました。

そして現在、 ts-toolbeltに同梱されています。

ただし、この提案は、一般的なタプル操作をはるかに簡単にするための優れた構文糖衣です。

すでにmedium.comにありますか？ URL？

Mediumに関する元の記事がありますが、ボーナスは含まれていません。リポジトリにあります。 また、作曲、パイプ、カレーを作成するための小さなツールをすべて作成した方法についても説明します：smile：

@ pirix-ghしかし、これはこの提案のように可変個引数のジェネリックではありません

declare function m<...T>(): T

m<number, string>() // [number, string]

@goodmindはい、そうではありません。もっとエミュレートされています。 したがって、次のように...エミュレートできます。

declare function m<T extends any[], U extends any[]>(): Concat<T, U>

m<[number, string], [object, any]>() // [number, string, object, any]

と同じです：

declare function m<...T, ...U>(): [...T, ...U]

m<number, string, object, any>() // [number, string, object, any]

その間、この提案を待っている間：hourglass_flowing_sand：

@ pirix-ghのようなラッピング機能を手伝ってくれませんか

type fn = <T>(arg: () => T) => T
let test1: fn
let res1 = test1(() => true) // boolean

type fnWrap = (...arg: Parameters<fn>) => ReturnType<fn>
let test2: fnWrap
let res2 = test2(() => true) // {}

作曲アプローチを使おうとして失敗しました。適切な方法で提案してもらえますか？

これは、ジェネリックスに依存するfnのパラメーター/リターンを抽出すると、TSがそれらを最も近いタイプに推測するために発生します（この場合、 Tはany ）。 したがって、現時点ではこれを行う方法はありません。 この提案がhttps://github.com/Microsoft/TypeScript/pull/30215と組み合わされるのを待つことをお勧めし

または、次のような方法でジェネリックを保存/移動する方法を見つけることができるかもしれません。

declare function ideal<...T>(a: T[0], b: T[1], c: T[2]): T

ideal('a', 1, {}) // T = ['a', 1, {}]

このようにして、その断片からfnを再構築します。 今日欠けている部分は、 @ goodmindが指摘したような一般的な部分です。

@ pirix-gh私が間違っていなければ、これを実行して、そこにあるものを達成することができます。

declare function MyFunction<A, B, C, Args extends [A, B, C]>(...[a, b, c]: Args): Args

const a = MyFunction(1, 'hello', true);
// typeof a = [number, string, boolean]

@ClickerMonkey正確ではありません。私が提案したものは、無制限の数の引数に対して機能するからです。 しかし、おそらく私たちはあなたが提案したものでこれを行うこともできます（私は提案でそれを見ていません）：

declare function MyFunction<A, B, C, ...Args>(...[a, b, c]: Args): Args

const a = MyFunction(1, 'hello', true);
// typeof a = [number, string, boolean]

@ pirix-gh例のA 、 B 、およびC型の引数は使用されていません。

-declare function MyFunction<A, B, C, ...Args>(...[a, b, c]: Args): Args
+declare function MyFunction<...Args>(...[a, b, c]: Args): Args

可変個引数型が実装されていたとしても、前の2つの例ではおそらくコンパイルエラーが発生しますが、引数が3つしかない場合、可変個引数型のポイントは何ですか。

あなたの例は、可変個引数が必要な理由を示しているはずです。既存のTSコードで実行できる場合、それは原因をまったく助けません。

@goodmindはい、そうではありません。もっとエミュレートされています。 したがって、次のように...エミュレートできます。

declare function m<T extends any[], U extends any[]>(): Concat<T, U>

m<[number, string], [object, any]>() // [number, string, object, any]

と同じです：

declare function m<...T, ...U>(): [...T, ...U]

m<number, string, object, any>() // [number, string, object, any]

その間、この提案を待っている間⏳

Concat<>はどこで手に入れたのですか？

編集：ソースコードを見つけてもかまいません。

@ pirix-ghだから私はあなたの提案でこれをやろうとしましたが、それを理解することができませんでした。

〜問題は、クラスのctorのパラメーターを拡張しようとしていることです。これは、型の配列があるところまで機能しますが、ctorパラメーターに対してそれらを拡散できません。〜

Class Test {
  constructor(x: number, y: string) {}
}
let ExtendedClass = extendCtor<[number, string], [number]>(Test);

let instance = new ExtendedClass(1, '22', 2);

更新： ctor関数でスプレッドを使用しても機能することを気にしないでください。

これがソリューションのリンクです

唯一の問題は、TSがほぼ毎回クラッシュすることです：|
これがTypeScriptの言うことですType instantiation is excessively deep and possibly infinite.ts(2589)

アップデート2：
私は最初に新しいタイプを置くことによってそれを達成しました、それでもこれらのタイプをマージできることは素晴らしいことです。

// ...
type CtorArgs<T, X> = T extends (new (...args: infer U) => any) ? [...U, X] : never;
// To be used as CtorArgs<typeof Test, string>
// ...
let instance = new MyClass1('22', 2, 'check');

とは対照的に：

let MyClass1 = extendClass<typeof Test, string>(Test);

let instance = new MyClass1('check', '22', 2);

最終的な解決策へのリンク。

私が正しく理解していれば、 Object.assignは次のように宣言して、可変個引数を完全にサポートできます。

type Assign<T, U extends any[]> = {
  0: T;
  1: ((...t: U) => any) extends ((head: infer Head, ...tail: infer Tail) => any)
    ? Assign<Omit<T, keyof Head> & Head, Tail>
    : never;
}[U['length'] extends 0 ? 0 : 1]

interface ObjectConstructor {
  assign<T, U extends any[]>(target: T, ...source: U): Assign<T, U>
}

TypeScriptのlib.d.ts別の方法で宣言されている理由はありますか？

再帰的な条件型はサポートされていないため、使用していません（その説明については、＃26980を参照するか、そうしないように指示するこのコメントを参照してください）。 現在の交差点の戻りタイプを使用する場合は、＃28323があります。

@jcalz Minusタイプの動作を示す重いテストを作成しました。 4秒未満でMinus 216000回実行します。 これは、TSが再帰型を非常にうまく処理できることを示しています。 しかし、これはごく最近のことです。

どうして？ これはAnders：tada：（https://github.com/microsoft/TypeScript/pull/30769）のおかげです。 彼は私が条件付きタイプからインデックス付き条件（スイッチのような）に切り替えることを許可してくれました。 実際のところ、ts-toolbeltのパフォーマンスは6倍向上しました。 彼にとても感謝しています。

したがって、技術的には、ts-toolbeltを使用して@kimamulaの型を安全に書き直すことができます。 複雑さはO（n）に従います。

import {O, I, T} from 'ts-toolbelt'

// It works with the same principles `Minus` uses
type Assign<O extends object, Os extends object[], I extends I.Iteration = I.IterationOf<'0'>> = {
    0: Assign<O.Merge<Os[I.Pos<I>], O>, Os, I.Next<I>>
    1: O
}[
    I.Pos<I> extends T.Length<Os>  
    ? 1
    : 0
]

type test0 = Assign<{i: number}, [
    {a: '1', b: '0'},
    {a: '2'},
    {a: '3', c: '4'},
]>

libはまた、TypeScriptからのオーバーフローを防ぐIterationで再帰を安全にします。 つまり、 Iが40超えると、オーバーフローし、 Pos<I>はnumber等しくなります。 したがって、再帰を安全に停止します。

私が書いた同様の再帰型（ Curry ）はRamdaに

ちなみに、プロジェクトのページでアドバイスをありがとうございました（@jcalz）。

＃5453がこの議論をするのに最適な場所であるかどうかはわかりません...これについては＃26980で話し合うべきですか、それとももっと標準的な場所がありますか？ いずれにせよ、私はおそらく活字体の今後のリリース時に内破ないであろう、これを行うには、公式及びサポートされている方法を持っているのが大好きです。 ベースラインテストに含まれているもので、壊れた場合は修正されます。 パフォーマンスが良好であることがテストされたとしても、@ ahejlsbergのような誰かからの公式の言葉がなければ、本番環境でこれを行うことには注意が必要です。

ベースラインテストに含まれているもので、壊れた場合は修正されます。

内部でかなり近いものが使われていると思います

@weswighamは密集していることを許してくれますが、強調表示されたタイプがどのように再帰的であるかを教えていただけますか？ 気になるのは形です

type Foo<T> = { a: Foo<Bar<T>>, b: Baz }[Qux<T> extends Quux ? "a" : "b" ]

または私が見た変種のいずれか。 私が何かを逃していて、これが何らかの緑色のライトを与えられている場合は、誰かが私に知らせてください（そしてそれの使い方を教えてください！）

ああ、公平だ-そういう点では違う。 「タイプを選択するためにすぐにインデックス付けされたオブジェクト」パターンと言うだけで、_that_があることに気づきました。

質問があります。

ここで提案されたもののどれだけがまだ関連していますか？ この号は4年前に発行されましたが、それ以来、多くのことが変わったように感じます。

ここでの私のコメントから、
https://github.com/microsoft/TypeScript/issues/33778#issuecomment -537877613

私は言った、

TL; DR、タプル型、レスト引数、マップされた配列タイプ、非レスト引数のタプル推論、再帰型エイリアス=変数型引数のサポートは実際には必要ありません

しかし、既存のツールでは単純に有効にできないユースケースがあるかどうかを知りたいです。

Concat<T extends any[], U extends any[]>公式に祝福されたバージョンを入手するまで、これは依然として関連性があります。 今後の再帰型参照機能がこれを私たちに与えるとは思いませんが、（正式に）別の方法で言われることを嬉しく思います。

Concat<>実装はもうありませんか？

それとも、ここでのキーワードは「公式に祝福されている」のでしょうか。

私の主張は、たとえそれが完全に「公式に祝福されていない」としても、基本的にあなたが現時点で望むことができるすべて（またはほとんどすべて？）を行うことができるということです。

しかし、私は「公式に祝福された」が常に好まれるべきだと思います...良い点。 私はそれらの再帰型エイリアスを（ab）使用することにあまりにも慣れています

私は一般的に、本物のエレガントな構文を好みます。そうすれば、このようなことをするたびに、（多くの場合、ジュニアの）チームメートに、現状の乱用が必要とする紛らわしい指定の型について何が起こっているのかを説明し続ける必要がなくなります。 その混乱は、私の組織でTypeScriptを伝道する私の能力、または少なくともこれらの使用法に悪影響を及ぼします。

これで大きな👍！

この機能はとても重要です。

@AnyhowStep

私の主張は、基本的に、現時点で必要なすべて（またはほとんどすべて？）を実行できるということです。

スプレッドパラメータを複数の単一パラメータと一緒に入力することが、今日のTSで簡単に達成できるという証拠は見当たりません。

@ matthew-学部長は完全に真実ではありません。 これはあなたがある程度達成するかもしれない例です。

私が理解しているように、TSはできるだけ多くのバニラJSプログラムを入力しようとしています。 ここにパズルがあります：

const f = <T extends any[]>(...args: T): T => args;
const g = <T extends any[]>(...a: T): WhatExactly<T> => {
    return f(3, ...a, 4, ...a, 5);
}
g(1, 2);

そこにあるタイプは[number, ...T, number, ...T, number]よりも複雑ではないと思います。 バグを悪用する奇妙なコードを20行記述しなければならない場合は、最後の行に適切な戻り型があることを確認してください。この問題は解決されていません。

@ polkovnikov-ph現在、タイプは[number, ...any[]]と推測されていますが、これは役に立ちません。

また、C ++はすでにすべてのHead<>とCons<>を通過しているため、C ++のように15年間Greenspunの10番目のルールを尊重する必要がないことにも注意したいと思います。非常に便利でクリーンな可変個引数テンプレート構文を考案しました。 私たちは（数百年の）開発者の時間を節約し、そこから最高の部分を取り出すことができます。

例えば、可変引数の型が異なる持っている種類あなたはタイプが期待されている可変引数の型変数を使用することはできませんので、タイプとは異なり、C ++でのそのextends any[] TSインチこれにより、C ++は、省略記号演算子で囲まれた式の内部で可変個引数型変数に言及することにより、タプルをマップ/圧縮できます。 これは、マップされたオブジェクトタイプのタプルの代替手段です。

type Somethify<...T> = [...Smth<T>]
type Test1 = Somethify<[1, 2]> // [Smth<1>, Smth<2>]

type Zip<...T, ...U> = [...[T, U]]
type Test2 = Zip<[1, 2], [3, 4]> // [[1, 3], [2, 4]]

type Flatten<...T extends any[]> = [......T]
type Test3 = Flatten<[[1, 2], [3, 4]]> // [1, 2, 3, 4]

extends any[]代わりに提案された省略構文が例で使用されているのは、美的理由だけでなく、

type A<T> = any[]
type B<T extends any[]> = [...A<T>]
type C = B<[1, 2]>

はすでに有効なTSプログラムです。 Cは、マップされた可変個引数タイプが生成する[any[], any[]]ではなく、 any[]になります。

@DanielRosenwasserこのようにpingを

余談ですが、可変個引数の種類がないために型パラメーターで使用できない場合でも、タプル型の型レベルの拡散操作があるだけで、私のチームにとって大きな助けになります。 私たちの問題領域では、「何らかの構造を持つ配列」が非常に一般的です。 この操作が機能する場合、それは私たちにとって物事を大幅に単純化するでしょう：

type SharedValues = [S1, S2, S3];
type TupleOfSpecificKind = [V1, ...SharedValues, V2];

@sethfowler表現したいことの例があれば、それは私たちにとって常に役に立ちます。 それ以外の場合は、 https：//github.com/microsoft/TypeScript/issues/26113に興味があるかもしれません

@DanielRosenwasser確かに、私は物事をもう少し具体的にすることができます。 本質的なことは避けますが、大まかに言えば、私たちのプロジェクトは、リモートサーバーに送信されるグラフィックス操作やその他の同様のイベントのストリームを生成するものと考えることができます。 効率上の理由から、これらの操作をメモリ内でシリアル化された形式に直接変換できる形式で表す必要があります。 これらのイベントのタイプは、次のようになります。

type OpLineSegment = [
  StrokeColor,
  FillColor,
  number,  // thickness
  number, number, number,  // X0, Y0, Z0
  number, number, number  // X1, Y1, Z1
];
type OpCircle = [
  StrokeColor,
  FillColor,
  number, number, number,  // X, Y, Z of center
  number // radius
];
type OpPolygon = (StrokeColor | FillColor | number)[];  // [StrokeColor, FillColor, repeated X, Y, Z]]
type OpFan = (StrokeColor | FillColor | number)[];  // StrokeColor, FillColor, repeated X, Y, Z up to 10x

これらのタイプを次のように表現できるようにしたいと思います。

type Colors = [StrokeColor, FillColor];
type Vertex3D = [number, number, number];

type OpLineSegment = [...Colors, number /* thickness */, ...Vertex3D, ...Vertex3D];
type OpCircle = [...Colors, ...Vertex3D, number /* radius */];
type OpPolygon = [...Colors, ...Repeated<...Vertex3D>];
type OpFan = [...Colors, ...RepeatedUpToTimes<10, ...Vertex3D>];

これらのコマンドは膨大な数あるため、タイプレベルのスプレッドがあるだけで、コードの保守性が大幅に向上します。 Repeated<>やRepeatedUpToTimes<> （この例では再帰的に定義されたタプル型の和集合に評価されます）のような型レベルの関数を記述できるように可変個引数を使用すると、さらに単純化できます。

また、タプル型の型セーフな連結などをサポートすることも非常に役立ちます（OPで説明されています）。 上記のタイプを使用するには、現在、タプル全体を単一のタプルリテラル式で作成する必要があります。 現在、部分的に構築して連結することはできません。 つまり、以下の操作は今日は機能しませんが、実際に機能することを願っています。

const colors: Colors = getColors();
const center: Vertex3D = getCenter();

// Doesn't work! Produces a homogenous array.
const circle1: OpCircle = [...colors, ...center, radius];

// Doesn't work; can't write this function today.
const circle2: OpCircle = concat(colors, center, radius);

// We need to do this today; it's quite painful with more complex tuple types.
const circle3: OpCircle = [colors[0], colors[1], center[0], center[1], center[2], radius];

これらの例がお役に立てば幸いです。

あなたは簡単に書くことができますConcat<>と入力し、作るConcat3<>タイプを使用して、 Concat<> 。

それで、

type OpCircle = Concat3<Colors, Vertex3D, [number] /* radius */>;

上記から、2、3、4、5、6などのオーバーロードを持つconcat関数を記述できます。 引数の数。

タプルのタプルを取り、タプルを連結するConcat <> implを作成することも可能です。 var-arg Concat <>タイプ。

今日はできないことではありません。 再帰型とヘルパー関数を書く必要がある場合でも、それを行うことができます。

vscodeでこれらの再帰型を使用するたびに、TSはCPUを強制終了したい、またはハングするだけです。 それが主な問題です。理由もなくTSが重くなりすぎているように感じます。

たぶん、型を書いている人々はそれを最適化するのに十分なことをしていませんか？

このスレッドにあまり価値をもたらさない古い会話をスパムしたりドラッグしたりしたくないのですが、JavaScriptでは再帰的な条件型の計算にコストがかかると聞いたことがあります（このスレッドで見つけました）

そうは言っても（クレイジーに聞こえるかもしれませんが）、TSはすでに大きく成長しているので、より良いものを求めるのが合理的であるため、型システムを後押しできるように、TSを別の言語で書き直す時が来たのかもしれません。

あなたは簡単に書くことができますConcat<>と入力し、作るConcat3<>タイプを使用して、 Concat<> 。

説明しているConcat<>タイプの実装を提供していただけますか？ Cons<>を書くのは簡単ですが、 Concat<>は（私にとって）それほど簡単ではないので、あなたが何を想像しているのか見てみたいです。

Concat3<> 、 Concat4<>などに関しては、可変個引数の種類があるため、長期的にはこれらのような数十のバリアントを作成する必要がないことが期待されます。 🙂しかし、それらの適切な実装が今日可能である場合、それは合理的な一時的な対策になります。

2つのタプルを定期的に連結する場合は、
https://github.com/AnyhowStep/ts-trampoline-test （トランポリンを使用して、ほとんどの人が必要としない非常に大きなタプルを連結します）

Concat3はConcatになります、C>

VarArgConcatは、
VarArgConcat<TuplesT extends readonly (readonly unknown[])[], ResultT extends readonly unknown[] = []>

タプルが空ではない間、 VargArgConcat<PopFront<TuplesT>, Concat<ResultT, TuplesT[0]>>

TuplesTが空の場合、ResultTを返します

もちろん、素朴な再帰は、まともな長さのタプルで最大深度エラーにつながります。 したがって、ts-toolbeltで再帰手法を使用するか、目的の深さまでコピーして貼り付けるトランポリンを使用します。

それは私が用途にリンクされているレポReverse<>実装するConcat<> 。 作業中の別のプロジェクトからコードをコピーして貼り付けました。

これが非常に便利な機能になることに同意します。

タイプTがあるとしましょう：

type T = {
  tags: ["a", "b", "c"];
};

そして、 T["tags"]タプルに追加されたタグ"d"を使用して、新しいタイプを作成します。 ユーザーは最初にこのユーティリティ（ WithTag<NewTag, ApplyTo> ）を次のように作成しようとします。

type WithTag<
  Tag extends string,
  Target extends {tags: string[]}
> = Target & {
  tags: [Tag, ...Target["tags"]];
};

これを試みると、現在エラーA rest element type must be an array typeスローされます。 ユーザーは、 string[]をArray<string>交換すると違いがあると思うかもしれませんが、違いはありません。 条件を使用することもありません+ never ：

type WithTag<
  Tag extends string,
  Target extends {tags: string[]}
> = Target & {
- tags: [Tag, ...Target["tags"]];
+ tags: Target["tags"] extends string[] ? [Tag, ...Target["tags"]] : never;
};

遊び場リンク： https://www.typescriptlang.org/play?#code/C4TwDgpgBA6glsAFgFQIYHMA8AoKU3pQQAewEAdgCYDOU1wATnOegDS76oPoTBGkUaUAN7AM1AFx1GzdAG0AugF9sAPigBeTt15QAZCI5j0kqHIKsoAOhtodwOQCJj1RwoUBubEq -ZQkKABJTUM8FyknVEdLRwAjaKhHAGM3Lx9sP3BoZBD4JAJMR0oEwNVfAHoAKkrcSqgAUWJIJLJKKAADZHaoYAB7KFjoXoAzHsRoYd6AGynegHdZHqyrWqhV4VWe8QjHKJj4mJSY4s9VlShK8qA

関連する問題::

• https://github.com/microsoft/TypeScript/issues/33783
• https://github.com/microsoft/TypeScript/issues/16746
• https://github.com/Microsoft/TypeScript/issues/26058

残念ながら、この戦略はRESTパラメーターでは機能しません。 これらは配列に変換されます：

function i(a: number, b?: string, ...c: boolean[]): number {
}
let curried = curry(i, 12);
curried('foo', [true, false]);
curried([true, false]);

ここで、カレー： ...([string, boolean[]] | [boolean[]]) => number 。
これは、タプルの最後の要素が配列である、タプルのRESTパラメーターを持つ関数に特別な場合がある場合にサポートできると思います。
その場合、関数呼び出しにより、正しい型の追加の引数が配列と一致するようになります。
しかし、それは複雑すぎて価値がないようです。

これには2つの問題があります。

1. コードが正しくありません。 curried()は配列を受け入れません。 c restパラメーターに[true, false]することは、 curried('foo', ...[true, false])によって実行できますが、この提案ではTypeScriptで失敗します。 場合によってはタイピングソリューションを提供できないこともありますが、間違った人を提供することはお勧めしません。
2. 意図せずに、オプションのパラメーターとRESTパラメーターを組み合わせて、提案のバグを明らかにしました。 curried()は、 bなしでは呼び出すことができませんが、 c呼び出すことができます。 そうすることは、不正行為につながります。 TypeScriptはcurried()が(...items: [string, boolean[]] | [boolean[]])ことを知っていますが、[true, false]をcに渡して（上記の問題を解決したと仮定）、 curried([true, false])を指定しても、 bはundefined設定されません。 cを[true, false]に設定しますが、 bをtrue 、 cを[false] ！

次の修正をお勧めします。

1. 2番目の（そしてより簡単な）問題の場合、解決策は単純です。restパラメーターがある場合、最後のオプションの引数（つまり、この場合は[number, string, boolean[]] | [number, boolean[]] ）のユニオンタプルを推測しないでください。 代わりに、 [number, string, boolean[]] | [number]推測します。つまり、すべてのオプションと残りを含む完全な署名の1つのケース、最後を除く各オプションに1つ、最後と残りのないケースに1つずつ推測します。
2. 最初の問題はもっとトリッキーです。あなたはすでに、複雑すぎて価値がないと思っていると言っています。 RESTパラメーターの人気を考えると、それは価値があると思いますが、最初の問題（勝利！😄）のために_必要_です。 tuple-with-last-rest-arrayのインターフェース（構文[t1, t2, t3, ...arr]について考えます）を公開するといいと思いますが、そうする必要はありません。 内部としてそのまま使用できます（ハハ、IDEでタイプを表示する方法を処理する必要があります😈）。

しかし、すべての苦情と挑発的な後、素晴らしい提案！ ありがとう👍（あなたを落ち着かせるために、これは私が3つの絵文字で応答したGitHubでの最初の問題です-👍、🎉、❤️）。

これは、現在anyを使用する必要があるAngularInjectorで非常に役立ちますhttps://github.com/angular/angular/issues/37264

この例では、A、B、Cは、単一の...A可変個引数ジェネリック型として表すことができます。 しかし、これが可変個引数ジェネリックの各要素が別のタイプ（ Type ）で囲まれているものにどのようにマッピングされるかはわかりません。 多分ヘルパータイプで？ または、構文で...Type<A>ようなものを許可する必要がありますか？

export declare interface TypedFactoryProvider<T, A, B, C> {
    provide: Type<T | T[]> | InjectionToken<T | T[]>;
    multi?: boolean;
    useFactory: (a: A, b: B, c: C) => T;
    deps: [Type<A>, Type<B>, Type<C>];
}

（コンテキスト： Providerを実装すると、 depsインスタンスがそのファクトリ関数にこの順序で挿入されます。厳密に入力すると、開発者は何がどの順序で挿入されるかを確実に知ることができます。）

これが完了したら、String.prototype.replaceの2番目のパラメーターを更新して、最終的にTypescriptで適切に入力できるようにしてください。

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replace#Specifying_a_function_as_a_parameter

@Griffork正規表現を解析して、キャプチャグループがいくつあるかを把握する必要があることを

これは、現在any angle / angular＃37264を使用する

この例では、A、B、Cは、単一の...A可変個引数ジェネリック型として表すことができます。 しかし、これが可変個引数ジェネリックの各要素が別のタイプ（ Type ）で囲まれているものにどのようにマッピングされるかはわかりません。 多分ヘルパータイプで？ または、構文で...Type<A>ようなものを許可する必要がありますか？

export declare interface TypedFactoryProvider<T, A, B, C> {
  provide: Type<T | T[]> | InjectionToken<T | T[]>;
  multi?: boolean;
  useFactory: (a: A, b: B, c: C) => T;
  deps: [Type<A>, Type<B>, Type<C>];
}

（コンテキスト： Providerを実装すると、 depsインスタンスがそのファクトリ関数にこの順序で挿入されます。厳密に入力すると、開発者は何がどの順序で挿入されるかを確実に知ることができます。）

@AlexAegis

次のように入力されると思います。

export declare interface TypedFactoryProvider<T, ...P> {
  provide: Type<T | T[]> | InjectionToken<T | T[]>;
  multi?: boolean;
  useFactory: (...providers: ...P) => T;
  deps: [...Type<P>];
}

この問題は、TS 4.0で予定されている＃39094で修正されています。

これが4.0に付属している場合は、4.0と名付ける理由があります😃
これは本当に主要な新機能です🎉

これは素晴らしい！ 「左」のものだけがリテラル文字列型で同じです

@sandersn pipeメソッドパラメータが相互に依存しているRxJSようなもので、この構文がどのように使用されるかを考えようとしています。

pipe(map<T, V>(...), map<V, U>(...), filter(...), ...) 。 彼らが今していることとは違う方法でそれをどのようにタイプしますか？ （可変個引数の長さが異なる数十行の入力）

@ahejlsbergが提出したPRを使用した@gioraguttこれはうまくいくと思いますが、間違っている可能性があります😄

type Last<T extends readonly unknown[]> = T extends readonly [...infer _, infer U] ? U : undefined;

interface UnaryFunction<T, R> { (source: T): R; }

type PipeParams<T, R extends unknown[]> = R extends readonly [infer U] ? [UnaryFunction<T, U>, ...PipeParams<R>] : [];

function pipe<T, R extends unknown[]>(...fns: PipeParams<T, R>): UnaryFunction<T, Last<R>>;

@tylorr円形型エラーに起因するんではない、かなりの仕事、。

ただし、通常の回避策は機能します。

type Last<T extends readonly unknown[]> = T extends readonly [...infer _, infer U] ? U : undefined;

interface UnaryFunction<T, R> { (source: T): R; }

type PipeParams<T, R extends unknown[]> = {
    0: [],
    1: R extends readonly [infer U, ...infer V]
    ? [UnaryFunction<T, U>, ...PipeParams<U, V>]
    : never
}[R extends readonly [unknown] ? 1 : 0];

declare function pipe<T, R extends unknown[]>(...fns: PipeParams<T, R>): UnaryFunction<T, Last<R>>;

@isiahmeadowsそれは私にはうまくいかないようです。 😢
遊び場の例。

私は仕事に近いものを手に入れましたが、それはタイプを推測しません。
遊び場の例

私は変えなければなりませんでした
R extends readonly [unknown] ? 1 : 0
に
R extends readonly [infer _, ...infer __] ? 1 : 0

理由がわからない

@tylorr @treybrisbane関連している可能性があります： https ：

また、どちらの場合でも、コメントが含まれているプルリクエストでそれを共有することを強くお勧めします。

可変個引数タプルタイプは言語への素晴らしい追加です、努力に感謝します！

curryような構成も役立つ可能性があるようです（ステージングプレイグラウンドでテストしただけです）。

// curry with max. three nestable curried function calls (extendable)
declare function curry<T extends unknown[], R>(fn: (...ts: T) => R):
  <U extends unknown[]>(...args: SubTuple<U, T>) => ((...ts: T) => R) extends ((...args: [...U, ...infer V]) => R) ?
    V["length"] extends 0 ? R :
    <W extends unknown[]>(...args: SubTuple<W, V>) => ((...ts: V) => R) extends ((...args: [...W, ...infer X]) => R) ?
      X["length"] extends 0 ? R :
      <Y extends unknown[]>(...args: SubTuple<Y, X>) => ((...ts: X) => R) extends ((...args: [...Y, ...infer Z]) => R) ?
        Z["length"] extends 0 ? R : never
        : never
      : never
    : never

type SubTuple<T extends unknown[], U extends unknown[]> = {
  [K in keyof T]: Extract<keyof U, K> extends never ?
  never :
  T[K] extends U[Extract<keyof U, K>] ?
  T[K]
  : never
}

type T1 = SubTuple<[string], [string, number]> // [string]
type T2 = SubTuple<[string, number], [string]> // [string, never]

const fn = (a1: number, a2: string, a3: boolean) => 42

const curried31 = curry(fn)(3)("dlsajf")(true) // number
const curried32 = curry(fn)(3, "dlsajf")(true) // number
const curried33 = curry(fn)(3, "dlsajf", true) // number
const curried34 = curry(fn)(3, "dlsajf", "foo!11") // error

ただし、上記のカレーでは総称機能は機能しません。

このPRがこの特定の問題を解決するとは思わない。

PRでこれは機能します

function foo<T extends any[]>(a: [...T]) {
  console.log(a)
}

foo<[number, string]>([12, '13']);

しかし、この問題は、私が見る限り、これの実装を見たいと思っています。

function bar<...T>(...b: ...T) {
  console.log(b)
}

bar<number, string>(12, '13');

そこにはたくさんの山かっこがあり、少し冗長に見えます。

@AlexAegisそのような「

declare function foo<T extends any[]>(...a: T): void;

foo(12, '13');  // Just have inference figure it out
foo<[number, string]>(12, '13');  // Expclitly, but no need to

推論が理解できないまれなケースで角括弧を回避できるようにするために、まったく新しい概念（つまり、RESTタイプのパラメーター）が本当に必要だとは思わないでください。

@ahejlsbergなるほど。 一部のライブラリ（前述のRxJS）がこの機能を提供するために回避策を使用したため、私は尋ねていました。 しかし、それは有限です。

bar<T1>(t1: T1);
bar<T1, T2>(t1: T1, t2:T2);
bar<T1, T2, T3>(t1: T1, t2:T2, t3: T3, ...t: unknown) { ... }

だから今、彼らはそれに固執するか、ユーザーに角かっこを入力させるかのどちらかです。これは重大な変更であり、それほど直感的ではありません。

この例を使用した理由は、ここでそのタプルのタイプを定義したのは簡単だからです。 ここに角括弧が1つ、そこに1つ

foo<[number, string]>([12, '13']);

ここでは、外部から見た場合、タプルがそのRESTパラメーターを参照していることはそれほど明白ではありません。

foo<[number, string]>(12, '13'); 

しかし、あなたが言ったように、推論にそれを理解させれば、これらの些細なケースはユーザーからの変更を必要としません。 しかし、彼らがそれらを明示的に設定したかどうかはわかりません。それは彼ら次第なので、それでも重大な変更としてカウントされます。 しかし、それはlibの関心事であり、この変更の関心事ではありません。

とはいえ、外側から1つずつ定義され、内側に...で区別される単一の配列であるRESTパラメーターがある場合、同じ方法で1つずつジェネリックにすることができないのは奇妙だと思います。外側は単一の配列、内側は...で区別されます。

マイナーな構文の不一致は、個別のサポートコストの価値がありません
親切。 TSが計画を立てていたとき、種類を使用することは正しい設計上の決定です。
残りのパラメーターのサポートですが、今ではもっと多くのことが起こるかもしれないと思います
言語開発者とユーザーの両方にとって混乱。 のソリューションが必要でした
この問題、そしてアンダースはそれを避けて非常にうまく仕事をしました
こだわることにより、複雑[...T]の代わりにT 。 脱帽！

（交差型を統合するバグを見てみましょう
条件型の推定変数は、右端の交差型を返します
引数、または配列の和集合は和集合の配列ではありませんか？ 私たちはまだ
型システムに主要なショートッパーがあります。）

金、2020年6月19日には、午前10時41Győriシャーンドルの[email protected]は書きました：

@ahejlsberghttps ：//github.com/ahejlsbergなるほど。 私が尋ねていたのは
一部のライブラリ（前述のRxJS）は、これを提供するために回避策を使用しました
機能。 しかし、それは有限です。

バー（t1：T1）;バー（t1：T1、t2：T2）;バー（t1：T1、t2：T2、t3：T3、... t：不明）{...}

だから今、彼らはそれに固執するか、ユーザーに角かっこを入力させるかのどちらかです、
これはそれほど直感的ではありません。

この例を使用した理由は、ここでは簡単だからです
そのタプルのタイプを定義しました。 ここに角括弧が1つ、そこに1つ

foo <[数値、文字列]>（[12、'13 ']）;

ここでは、タプルがそのRESTパラメーターを参照していることはそれほど明白ではありません。
外から見る

foo <[数値、文字列]>（12、 '13'）;

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/microsoft/TypeScript/issues/5453#issuecomment-646490130 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAWYQIMTTB6JEPSQFUMTMDTRXMJD5ANCNFSM4BTBQ7DQ
。

もちろん、私は彼の口径にはほど遠いですが、 ます。
私の経験では、typescriptの複雑さの多くは、多くの（興味深く、確かに役立つ）機能が独自の概念として特別に使用されているという事実に起因しています。

ただし、この複雑さは本質的に機能の数の関数ではありません。
代わりに、言語は、これらの特殊なケースを簡単に推測したり、std（タイプ）ライブラリに実装したりできる、より大きく、より包括的な概念に基づいて設計することができます。

もちろん、最も一般的なそのような概念は、依存型を完全に実装することであり、そこから他のすべてを導き出すことができますが、そこまで進む必要はありません。
C ++と、程度は少ないがRustが示したように、いくつかの大規模で一貫性のある概念により、大量の機能が無料で提供されます。
これは、OCamlとHaskell（そして私はF＃だと思いますか？）が値レベルで、ちょうどタイプレベルで行ったことに似ています。

型レベルのプログラミングは、特定の機能を提供するために追加されるのではなく、言語に合わせて設計されている限り、恐れることはありません。
C ++ 14/17の機能は、構文が純粋に過去の手荷物によるものであることを除けば、非常に直感的です。

包括的な概念が元の設計に追加された可能性があります。 設計後
間違いはすでに行われており、大きなリスクを冒さずに一貫性を追加することはできません
バック非互換性。 私は言語デザインに関する疑惑に同意します
全体（TSは学界によって設定された基準からかなり遠いです、誰もできません
それに同意しません）。 バグや矛盾がたくさんあります
何百万ものプロダクションコードベースの基盤です。 ただの事実
開発者は言語への便利な追加を思い付くことができます
誤ってそれらのバグを修正することなく、私の謙虚な意見では、素晴らしいです
そして尊敬に値する。 TSはここではC ++と同じ設計の複雑さを持っていますが、
表現型システムは状況を悪化させます。

金、2020年6月19日には、午前12時47分ベネットPiaterの[email protected]は書きました：

もちろん私は彼の口径にはほど遠いですが、私は敬意を表して反対します
@ahejlsberghttps ：//github.com/ahejlsbergを使用します。
私の経験では、typescriptの複雑さの多くは多くの（興味深く、確かに役立つ）機能が独自のコンセプトとして特別なケースに入れられます。

この複雑さは、本質的に機能の数の関数ではありません
けれど！
代わりに、言語はより大きく、より包括的なものを中心に設計することができます
これらの特殊なケースを簡単に推測できる概念、または
std（タイプ）ライブラリに実装されています。

もちろん、最も一般的なそのような概念は、完全に実装することです。
依存型。他のすべてを派生させることができますが、
そこまで行く必要はありません：
C ++として、そして程度は少ないが、Rustが示したように、いくつかの大規模な
一貫したコンセプトにより、たくさんの機能が無料で提供されます。
これは、OCamlとHaskell（そして私はF＃だと思いますか？）が行ったことと似ています
タイプレベルだけの値レベル。

型レベルのプログラミングは、それがそうである限り、恐れることは何もありません。
特定の情報を提供するために取り組むのではなく、言語に合わせて設計されています
特徴。
C ++ 14/17の機能は、構文を除いて非常に直感的です。
これは純粋に歴史的な手荷物によるものです。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/microsoft/TypeScript/issues/5453#issuecomment-646543896 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAWYQIMWYLGGCWPTDBZJR4TRXMX4RANCNFSM4BTBQ7DQ
。

@ polkovnikov-ph当面の問題に同意できてうれしいです:)

解決策としては、より慎重に設計された型システムに徐々に移行することを検討する価値があると思います。 結局のところ、メジャーバージョンは重要であり、代替手段は、C ++ 20であるクラスター**で終わることです-削除できない以前の試みの2つのレイヤーの上にさらにうまく設計された機能を追加する素晴らしい試みです。まだ決定論的に解析できない構文。

これらはすべてこのスレッドではトピックから外れており、ここで説明してい

学界がサブタイピングへの正しいアプローチを理解するのに数十年かかりました。mlsub型システムは、TypeScriptが最初にリリースされてからわずか6年前に作成されました。 それは、包括的な概念を持つクラス、インターフェース、和集合、および交差型の基盤である可能性があります。

ただし、条件型があることも忘れないでください。 正式なセマンティクスを提供している論文や、進行状況/保存証明を備えた条件付き型を使用した最小型システムについて説明している論文はありません。 それは、失敗した試みを印刷することにまだ恥ずかしがり屋である科学者と関係があるのではないかと思います。 あなたの提案がそれらの主要な互換性のないバージョンが2040年代に作られると仮定するならば、学界が条件付きタイプに慣れたとき、私は同意することができます。

そうでなければ、「慎重に設計された型システム」は言語から条件付き型を削除する必要があり、DefinitelyTypedの60％を変換して、それらを置き換えるために選択された代替手段を使用することは誰にもできないと思います。 （そして、それが唯一の問題ではないので、それをさらに数回行います。）

唯一の実行可能な解決策は、どういうわけかTSに似た別のプログラミング言語を作成することであり、どういうわけか（コードを書くのがより楽しいだけでなく）開発者にそれを使用するように誘惑することです。 ライアンは以前、TSの改善のためにこのアプローチを推奨することを非常に声高に言っていました。