@gcanitiはノイズについてお詫びし、追加の説明をありがとうございます。 コメントする前にもっと勉強すべきだった。 もちろん、（私はすでに知っている）ファンクターはインスタンスの実装を必要とするので、それは概念化における私の誤りです。

Afaics、あなたの巧妙な「ハック」は、ファクトリを一般的に参照することを可能にします（たとえば、 lift ）が、ファンクタの特殊なタイプの一般的なファクトリの各タイピングを（更新および）特殊化するためのモジュール拡張の追加の定型文が必要です例： Option 。 その定型文は、ジェネリックファクトリのすべてのジェネリック使用に必要ではないでしょうか。たとえば、ジェネリックsort例@keeanと私は話し合いました。 おそらく、他のコーナーケースも発見される可能性がありますか？

Kotlinはあなたのアイデアをコピーしましたか

私は否定的になりたくありませんが、これにリソースを投資しようとしているのであれば、それは考慮事項です。

ええ、その考えは私にも起こりました。 それを明確にしてくれてありがとう。 @masaeeduが指摘しているように、考慮事項の1つは、型システムへの一般的な影響と、型システムが生成する可能性のあるコーナーケースであると思われます。 これが非常に徹底的に考えられ、実証されない限り、おそらく抵抗があるでしょう。

_{また、EMCAScriptコンパイルターゲットへの投資のレベルをより正確に確認するために、Ceylonを調べていることに注意してください。 （もっと勉強する必要があります）。}

私もこの制限に噛まれたばかりです。 次の例のIを自動的に推測したいと思います。

interface IdType<T> {
  id: T;
}

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

function doStuff<T extends IdType<I>>() {
  const recs = new Map<I, T>();
  return {
    upsert(rec: T) {
      recs.set(rec.id, rec);
    },
    find(id: I) {
      return recs.get(id);
    },
  };
}

(function () {
  const stuff = doStuff<User>();
  stuff.upsert({id: 2, name: "greg"});
  console.log(stuff.find(2));
})();

私の知る限り、これにはより種類の多い型が必要であるか、冗長と思われる重複するジェネリックパラメーター（ doStuff<User, number>() ）を指定する必要があります。

私は最近、この制限にも打たれました。

私は約束のために図書館に取り組んできました。 それらを操作するためのさまざまなユーティリティ関数を提供します。

ライブラリの中心的な機能は、ライブラリ内に置いたのと同じタイプのpromiseを返すことです。 したがって、Bluebird promiseを使用していて、関数の1つを呼び出すと、Bluebirdpromiseとそれらが提供するすべての追加機能が返されます。

私は、型システムでこれをエンコードしたかったが、私はすぐにタイプでの作業、これが必要であることを実現P種類の* -> *ようにP<T> extends Promise<T> 。

このような関数の例を次に示します。

/**
* Returns a promise that waits for `this` to finish for an amount of time depending on the type of `deadline`.
* If `this` does not finish on time, `onTimeout` will be called. The returned promise will then behave like the promise returned by `onTimeout`.
* If `onTimeout` is not provided, the returned promise will reject with an Error.
*
* Note that any code already waiting on `this` to finish will still be waiting. The timeout only affects the returned promise.
* <strong i="14">@param</strong> deadline If a number, the time to wait in milliseconds. If a date, the date to wait for.
* <strong i="15">@param</strong> {() => Promise<*>} onTimeout Called to produce an alternative promise once `this` expires. Can be an async function.
*/
timeout(deadline : number | Date, onTimeout ?: () => PromiseLike<T>) : this;

上記の状況では、かなりハッキーなthisタイプを使用することで、より高い種類の必要性を回避することができました。

ただし、次の場合は解決できません。

/**
* Returns a promise that will await `this` and all the promises in `others` to resolve and yield their results in an array.
* If a promise rejects, the returned promise will rejection with the reason of the first rejection.
* <strong i="21">@param</strong> {Promise<*>} others The other promises that must be resolved with this one.
* <strong i="22">@returns</strong> {Promise<*[]>} The return type is meant to be `Self<T[]>`, where `Self` is the promise type.
*/
and(...others : PromiseLike<T>[]) : ExtendedPromise<T[]>;

this<T[]>か何かをすることを可能にするハックがないからです。

ドキュメントの私の小さな謝罪に注意してください。

上記の参考文献に示されているように、この機能が役立つと私が信じる別のシナリオを手に入れました（私が提案を正しく解釈したと仮定して）。

問題のパッケージでは、ジェネリック型は通常ユーザーが作成するため、型として使用される型なしのジェネリッククラスまたは関数が必要です。

私のシナリオに提案を適用すると、次のようになると思います。

import { Component, FunctionalComponent } from 'preact';

interface IAsyncRouteProps {
    component?: Component<~,~> | FunctionalComponent<~>;
    getComponent?: (
        this: AsyncRoute,
        url: string,
        callback: (component: Component<~,~> | FunctionalComponent<~>) => void,
        props: any
    ) => Promise<any> | void;
    loading?: () => JSX.Element;
}

export default class AsyncRoute extends Component<IAsyncRouteProps, {}> {
    public render(): JSX.Element | null;
}

私の実装ではジェネリック型を確実に参照する方法がないことを考えると、私は何かを見逃していると確信しています。

@ Silic0nS0ldier実際、そのケースは今すぐ解決できます。 次のような構造コンストラクタタイプを使用します。

type ComponentConstructor = {
    new<A, B>() : Component<A, B>;
}

そして、 component ?: ComponentConstructorと言います。

さらに一般的には、実際にはジェネリック関数型を持つことができます。

let f : <T>(x : T) => T

これはランクnパラメーター多相と呼ばれ、実際には言語では非常にまれな機能です。 したがって、TypeScriptに、はるかに一般的な機能である、より種類の多い型がない理由については、さらに不可解です。

ここで説明する制限は、特定のTComponent<T, S>を参照する必要がある場合に表示されます。 しかし、あなたの場合、これは不要のようです。

typeof Componentを使用して、コンストラクターComponentの型を取得することもできますが、これにより、サブタイプでさまざまな問題が発生します。

@GregRos提案されたソリューションは有望に見えましたが（定義ファイル内の型を受け入れます）、互換性のある型は拒否されています。 https://gist.github.com/Silic0nS0ldier/3c379367b5e6b1abd76e4a41d1be8217

@ Silic0nS0ldier要点についての私のコメントを参照してください。

@chrisdaviesこれは機能しますか？

interface IdType<T> {
    id: T;
}

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

function doStuff<T extends IdType<any>>() {
    type I = T['id']; // <==== Infer I
    const recs = new Map<I, T>();
    return {
        upsert(rec: T) {
            recs.set(rec.id, rec);
        },
        find(id: I) {
            return recs.get(id);
        },
    };
}

(function() {
    const stuff = doStuff<User>();
    stuff.upsert({ id: 2, name: "greg" });
    console.log(stuff.find(2));
})();

@ jack-ウィリアムズうん。 それは私のシナリオではうまくいきます。 私はドキュメントでその例を見つけていませんでした（私は物事が欠けていることで知られていますが！）。 ありがとうございました！

私はこの機能についてよく考えており、ある種の仕様に傾倒してこの問題についていくつか考えていますが、それでも多くの問題を見ることができます。 私の提案は、これまでに提案されたものとは少し異なります。

まず第一に、型コンストラクターにT<*, *>構文を使用することは、型コンストラクターの複雑さにうまく対応できないため、悪い考えだと思います。 また、型パラメーターを持つ関数であっても、関数に対してこれを行わないため、参照されるたびに型コンストラクターの種類を指定することに意味があるかどうかもわかりません。

これを実装する最良の方法は、他の型と同じように通常の名前でより種類の多い型を扱い、制約を課すために使用できる型コンストラクター自体に対して適切なサブ型関係を定義することだと思います。

ある種の接頭辞または接尾辞を使用して、他の型と区別する必要があると思います。主に、通常のコードを記述したいだけの場合に、型コンストラクターに関連する理解できないエラーメッセージからユーザーを保護するためです。 ~Type, ^Type, &Typeなどの外観が好きです。

したがって、たとえば、関数のシグネチャは次のようになります。

interface List<T> {
    push(x : T);
}

function mapList<~L extends ~List, A, B>(list : L<A>, f : (x : A) => B) : L<B>;

（私は意図的に構築された型に~プレフィックスを使用していません）

ここでextendsを使用することにより、基本的に2つのことを言いました。

** 1。 必要な場合： ~Lは、 ~Listと同じ種類の型コンストラクターです。つまり、種類* -> * （または、 =>なので* => * ）です。 =>はTypeScriptの矢印です）。

1. ~Lは~Listサブタイプです。**

extendsを使用して型コンストラクターの種類を示すと、 ((* => *) => (* => *)) => *などの任意の複雑な型コンストラクターにスケーリングされます。

タイプの識別子でその種類を実際に見ることはできませんが、私はあなたがそうする必要はないと思います。 型コンストラクター間のサブタイプ関係が型を保持する必要があるかどうかさえわからないので、（1）は必要ないかもしれません。

不完全な型の構築はありません

不完全な型の構築をサポートすべきではないと思います。 つまり、次のようなものです。

(*, *) => * => *

それは価値があるよりも多くの問題を引き起こすと思います。 つまり、すべての型コンストラクターは何らかの具象型を作成する必要があり、その具象型はTCが定義されているコンテキストで指定する必要があります。

型コンストラクターを定義する構造的な方法

また、非常に高次のジェネリック関数型を含め、他の型を構造的に指定できるのと同じように、型コンストラクターを指定する構造的な方法があるべきだと思います。 私は次のような構文を考えてきました：

~<A, B> { 
    a : A,
    b : B
}

これは、型パラメーターを持つ関数型の既存の構文に似ています。

<A, B>() => { a : A, b : B};

この2つを組み合わせてこれを取得することもできます。

~<A><B, C> => [A, B, C]

これは、ジェネリック関数型を構築する型コンストラクターです。

利点は、これらの構造型を他の構造型を指定するとき、型制約を指定するときなどに使用できることです。 これは、他の場所からは参照できない参照ローカルシンボルを使用できることを意味する場合があります。

次に例を示します。

type List<A, B> = ...;

type AdvancedType<~L extends ~<A>List<A, B>, B> = ...;

上記の例では、構造型コンストラクター~<A>List<A, B>は型パラメーターB参照しています。 少なくとも部分的に構築されたタイプList<A, *>をエンコードしない限り、この関係を他の方法で指定することはできません。 他の例もあります。

サブタイプの関係

サブタイプの関係は理にかなっているようですが、それを特徴づけるのに多くの困難に遭遇しました。

私の最初のアイデアは次のとおりでした。 ~Aが~Bサブタイプになる場合：

1. （a）それらは同じ種類でなければなりません（制約ではなく、アリティの観点から）。
2. （b） ~Aすべての正当なパラメーター化T₁, T₂, ...について、 A<T₁, T₂, ...>はB<T₁, T₂, ...>サブタイプでなければなりません。

ただし、これにはいくつかの制限があります。

1. クラスMySpecialPromiseはPromiseLike {}を実装します
   

2. クラスMyArrayPromisePromiseLikeを実装します

   この場合も、サブタイプの関係は保存されません。

（b）のより一般化されたバージョンは次のとおりです。

（b） ~Aすべての正当なパラメーター化T₁, T₂, ...に対して、 A<T₁, T₂, ...>がのサブタイプであるような~Bパラメーター化S₁, S₂, ...が存在します。 B<S₁, S₂, ...> 。

言い換えれば、上記の特性を備えたマッピングF （T1、T2、...）= S1、S2、...があります。 このマッピングは、パラメータ構築するために使用する必要がありますB<...>パラメータ化からA<...> 。 型コンストラクターの種類が異なっていても、これを実行できる場合があります。

この関係の問題は、正しいマッピングを見つける方法がわからないことです。 記名的型付けのある言語では、次の行に沿ったすべてのステートメント：

A<...> extends B<...>

~Aの型パラメーターと~Bの型パラメーターの間のマッピングを定義します。これにより、マッピングを復元できます。 ただし、TypeScriptの構造型付けのシステムでは、この型の明示的なステートメントに依存することはできません。

1つの方法は、 implements句や、Scalaに似たある種の抽象型メンバーなど、適切な型情報を持つ型の型コンストラクターのみをサポートすることです。 しかし、これが前進する方法かどうかはわかりません。

@ GregRos-興味深いメモ！ いくつかの質問。

具体的なタイプとはどういう意味ですか？ 種類が*何か、またはバインドされた型パラメーターのない型を意味しますか？

不完全な型の構築はありません
不完全な型の構築をサポートすべきではないと思います。 つまり、次のようなものです。
（*、*）=> * => *

不完全な型を作成するとはどういう意味ですか？ L<A>ようなすべてのアプリケーションは種類*を持つ必要があるということですか。 たとえば、ペアの種類のコンストラクターはあなたの例では特別ですか？ (* => *) => * => *は大丈夫ですか？

型コンストラクターを定義する構造的な方法

~<A, B> { 
    a : A,
    b : B
}

inferface TyCon<A, B> { 
    a : A,
    b : B
}

これらの例は、最初の例が匿名であることを除いて、異なりますか？

サブタイプの関係

~Aと~Bは型を参照していないので、サブ型の関係を持つことは理にかなっていますか？ あるコンストラクターが別のコンストラクターの「サブタイプ」であることを実際に確認する必要があるのはいつですか。 コンストラクターが適用されるまで待って、結果の型を確認することは可能ですか？

@ jack-williamsフィードバックをありがとう！

不完全な型を作成するとはどういう意味ですか？ L<A>ようなすべてのアプリケーションに種類*が必要だということですか。 たとえば、ペアの種類のコンストラクターはあなたの例では特別ですか？ (* => *) => * => *は大丈夫ですか？

はい、正確に。 L<A>ようなすべてのアプリケーションには、種類*です。 その上でどれだけ売れたかわかりません。

これらの例は、最初の例が匿名であることを除いて、異なりますか？

1つ目は型式で、2つ目は宣言です。 これらのタイプがほとんどの点で同一であるのと同じように、それらはほとんどの点で同一です。

{
     a : number;
     b : string;
}

interface Blah {
    a : number;
    b : string;
}

構文にはいくつかの動機があります。

1. TypeScriptの他のすべてと同様に、タイプコンストラクターを構造的かつ匿名で指定できます。
2. 型式（上記で型指定された匿名オブジェクトなど）は、関数の型シグネチャなど、宣言ステートメントを使用できない特定のコンテキストで使用できます。 これにより、ローカルIDを取得し、他の方法では表現できないものを表現できます。

~Aと~Bは型を参照していないので、サブ型の関係を持つことは理にかなっていますか？ あるコンストラクターが別のコンストラクターの「サブタイプ」であることを実際に確認する必要があるのはいつですか。 コンストラクターが適用されるまで待って、結果の型を確認することは可能ですか？

型コンストラクターは、型と見なされる場合と見なされない場合があります。 私はそれらを型と見なすことを提案します。値がなく、値の型を必要とするコンテキストに表示できない不完全なものです。 これは、このドキュメントでScalaが採用した哲学と同じです。

サブタイプ関係とは、本質的に、型コンストラクターを制約するために使用できるある種の「適合」関係を意味します。 たとえば、 Promise<T> 、 Bluebird<T> 、さまざまなタイプのあらゆる種類のpromiseで機能する関数を作成する場合は、TCパラメーターを制約する機能が必要です。何らかの方法でPromiseLike<T>をインターフェースします。

このタイプの関係の自然な言葉は、サブタイプの関係です。

例を見てみましょう。 型コンストラクター間のサブタイプ関係を作成したと仮定すると、次のような関数を記述できます。

function mapPromise<~P extends ~PromiseLike, A, B>(promise : P<A>, func : (x : A) => B) : P<B>;

そして、制約~P extends ~PromiseLikeは、これがpromiseで機能し、promiseのみで機能する関数であることを保証することになっています。 この制約は、関数の本体内で、 promiseがPromiseLike<A>などを実装することがわかっていることも保証します。 すべての後に、関数の本体に活字体によって認識メンバーが正確に制約を通じて存在することが証明できるものです。

同様に、 Promise<T> extends PromiseLike<T>は構造的に互換性があり、相互に置き換えることができるため、 ~Promise extends ~PromiseLike構造的に互換性のある型を構築するため、相互に置き換えることができます。

サブタイプの問題の問題を強調するために、もう一度検討してください。

interface MyPromise<T> extends Promise<T[]> {}

~Promise抽象化するのと同じ方法で、 ~MyPromiseで抽象化できますか？ それらの間の関係をどのように捉えますか？

私は以前の話マッピングは、のパラメータ与えられ、そのマッピングである~MyPromiseのパラメータ生成されます、 ~Promiseによって構築型のように~MyPromiseのサブタイプであります~Promiseによって構築されたもの。

この場合、マッピングは次のようになります。

T => T[]

@GregRos

この場合、 ~MySpecialPromiseは種類が異なるため、 ~PromiseLikeサブタイプではありません。

Haskellでは、この種の問題は、型の部分適用を許可し、最終的な型パラメーターが実装しているインターフェイスの型パラメーターと一致するように型を定義することで解決されます。

あなたの例では、 MySpecialPromiseはMySpecialPromise<TSpecial, TPromiseVal>として定義され、 ~MySpecialPromise<SpecialType>は~Promiseと同じ種類になります。

@GregRos

サブタイプ関係とは、本質的に、型コンストラクターを制約するために使用できるある種の「適合」関係を意味します。 たとえば、Promiseのように、さまざまなタイプのあらゆる種類のPromiseで機能する関数を記述したい場合、 青い鳥など、インターフェイスPromiseLikeを使用してTCパラメータを制約する機能が必要です。何らかの方法で。
function mapPromise<~P extends ~PromiseLike, A, B>(promise : P<A>, func : (x : A) => B) : P<B> ;

その関数の型チェックに関しては、選択したTに対してBlueBird<T>とPromiseLike<T>を統合しようとすると思いますが、これらは単なる具体的な型であり、サブタイプに分類されます。 コンストラクター~BlueBirdと~PromiseLike特別な関係が必要な理由がわかりません。

こんな感じで使われると思いますか？

let x: <P extends ~PromiseLike>(input : P<A>, func : (x : A) => B) : P<B>;
let y: <P extends ~BlueBird>(input : P<A>, func : (x : A) => B) : P<B>;
x = y;

ここで、yの制約がxの制約を意味することを確認したい場合がありますが、TypeScriptには、 BlueBird<T>が使用可能なPromiseLike<T>を拡張することを確認する機構がまだありませんか？

@ jack-williams次の制約をどのように指定するかによって決まります。

〜Pは、すべてのA 、 P<A>がPromiseLike<A>サブタイプであるような型コンストラクターです。

どのような構文を使用しますか？ どんなコンセプトを使いますか？ あなたはこのようなものを書くことができます：

function mapPromise<~P, A, B where P<A> extends PromiseLike<A>>

ただし、この構文には制限があります。 たとえば、このクラスを制約するために宣言された時点でタイプP<A>を構築できないため、このクラスをまったく表現できません。

class PromiseCreator<~P extends ~PromiseLike> {
    create<A>() : P<A>;
}

しかし、次のように、そのために実存型を使用できると思います。

//Here A is not a captured type parameter
//It's an existential type we introduce to constrain ~P
class PromiseCreator<~P with some A where P<A> extends PromiseLike<A>> {
    create<A>() : P<A>;
}

次に、オプションで存在型を使用して、関数または型のシグネチャ内で構築された型を介してすべての型コンストラクターを制約するように要求できます。

実存型の場合、これはマッピングとのサブタイプ関係と同じ表現力を持ちます。

ただし、これには複数の問題があります。

1. ((* => *) => *) => *などの種類で型コンストラクターを指定するには、多くの実存型を導入する必要があり、そのうちのいくつかは高階でなければなりません。 それらのすべては、関数またはクラスのシグニチャに出現する必要があります。
2. マッピングを見つけるよりも、問題の存在タイプを見つける方が簡単かどうかは完全にはわかりません。
3. サブタイプの関係よりもエレガントではないと思います。
4. 対処しなければならない別の形式のタイプを導入する可能性があります。

@GregRos

どのような構文を使用しますか？ どんなコンセプトを使いますか？

_個人的に_私は特別な構文を使用せず、次を使用します。

function mapPromise<P extends PromiseLike, A, B>(p: P<A>, f: (x: A) => B): P<B>

class PromiseCreator<P extends PromiseLike> {
    create<A>() : P<A>;
}

しかし、これはnumberようなものをnull-aryコンストラクターと見なしているので、私の意見です。したがって、区別する必要はありません。

コンストラクター関数のサブタイプに関する私の見解は、可能な限り単純に保つことです。 それらは同じアリティを持ち、パラメータは、Scalaの論文のように、反変性と共分散を考慮に入れて、互いにサブカインドである必要があります。

部分適用は、それらが異なるアリティを持っている場合を回避することができます（型コンストラクターの自動カリー化は気にしないので、 MySpecialPromise<SpecialType>書くだけです）。

interface MyPromise<T> extends Promise<T[]> {}の例では、正直に言うと、このケースを処理するのに複雑さの価値があるとは確信していません。これがなくても十分に役立つ機能だと思います。

その場合の処理​​は（私が思うに）次のように言うのと同じです： ~MyPromise extends ~(Promise . [])ここで、 []はリストコンストラクターで、 .はコンストラクター構成です。 コンストラクターの構造を調べるだけでは不十分なため、状況はさらに難しくなっているようですが、構成についても推論する必要があります。

@ jack-williamsこれはデフォルトの型パラメータでは機能しません。 P extends Fooと書くと、 Fooにはデフォルトの型パラメーター、つまりtype Foo<T = {}> = ...がありますが、 P種類は何ですか？

私は高次の型を承認していると言いたいだけです（実際のTypeScriptプロジェクトでは、それらが役立つ状況がありました）。

しかし、カリー化をサポートするべきではないと思います。 私はHaskellが大好きですが、それはTypeScriptには適合しません。

高次の型は、カリー化や部分適用がなくても便利ですが、部分適用が必要な

Foo<number, _>  // equivalent to `type Foo1<A> = Foo<number, A>`

@ cameron-martin

編集：申し訳ありませんが、私のコメントはあまり明確ではなかったと思います。 Pは独自の種類があります。つまり、使用によって種類が課せられます。 Say制約は常に最高の種類であると想定されるため、 Fooは~Fooと想定されます。 Pを強制的に下位の種類にする場合にのみ、 Fooにデフォルトパラメータがあるかどうかを確認します。 これに関する私の懸念は親切な推論ですが、その場合、 ~役に立たず、完全な注釈が必要だと思います。

Pは独自の種類がありますね？ 質問は、私たちが治療を行うことはないでしょうFooのように~Foo 、またはとしてFoo<{}> ：私はそれはP.だから、一種のによって駆動される主張するだろうもしPはデフォルトのパラメーターを強制する型であり、 Pがコンストラクター* => *場合、 Fooも同じように扱います。

@Pauanあなたの提案に同意します。

@ jack-williams先に述べたように、サブタイプの概念を検討しました。

私の最初のアイデアは次のとおりでした。 ~Aが~Bサブタイプになる場合：

1. （a）それらは同じ種類でなければなりません（制約ではなく、アリティの観点から）。
2. （b） ~Aすべての正当なパラメーター化T₁, T₂, ...について、 A<T₁, T₂, ...>はB<T₁, T₂, ...>サブタイプでなければなりません。

問題は、物事をできるだけ単純に保つと、逆説的で言語に適合しないサブタイプ関係になってしまうことです。

もしMyPromise<T> extends Promise<T[]>手段はMyPromise<T>使用可能でなければならどこでもPromise<T[]>使用可能ではありませんが、これはもはやケースだろう。

asを使用してa : MyPromise<T>をPromise<T[]> asに変換した場合、アップキャストになりますが、逆説的にa割り当てが容易になります。

既存のサブタイプの関係に従う既存の一般的な制約を使用して、同様の効果を達成し、奇妙な動作を引き起こすこともできます。

function id1<A, ~P extends ~PromiseLike>(p : P<A>) : P<A>;

function id2<A, P extends Promise<A[]>>(p : P) : P {
    //ERROR - P does not extend PromiseLike<A>
    return id1(p);
}

タイピングは、副作用としても少なくとも部分的には名目上のものになります。 これらのタイプは突然異なり、現在は同じです。

type GenericNumber<T> = number;

type RegularNumber = number;

型パラメーターを持つ複雑な結合/交差型、純粋な構造型、メンバー内包表記を持つ型などにどのような影響があるのか​​さえわかりません。

私の個人的な感想は次のとおりです。型コンストラクターに対するサブタイプの関係は、既存のものに反対するのではなく、尊重する必要があります。 悲しいことに、これにはもっと複雑なものが必要です。

型コンストラクターにある種の特別な表記法を使用する最大の理由は、99％の開発者が型コンストラクターが何であるかを知らず、それらに関するエラーメッセージで攻撃されたくないということです。

これは、すべての開発者が圏論の上級コースを受講することを法律で義務付けられているHaskellとは大きく異なります。

二次的な理由は、場合によっては（前述のデフォルトのパラメーターの場合のように）、構文があいまいになるか、特定の型コンストラクターをまったく抽象化できないことです。

編集：申し訳ありませんが@GregRos私はあなたの後者のコメントを見ません

型コンストラクターに対するサブタイプの関係は、既存のものに反対するのではなく、尊重する必要があります。

これが達成できれば、私は同意します。 私はすべての詳細とこれがどれほど簡単であるかについて頭を悩ませていません。

二次的な理由は、場合によっては（前述のデフォルトのパラメーターの場合のように）、構文があいまいになるか、特定の型コンストラクターをまったく抽象化できないことです。

制約を低くする必要があるまで、常に最高の種類の制約を想定すると、あいまいになることに同意するかどうかはわかりません。 これはアサーションではなく、他の例を示している場合は十分に公平です。

問題は、物事をできるだけ単純に保つと、逆説的で言語に適合しないサブタイプ関係になってしまうことです。

それは本当かもしれません、私は代替案が実際に実装できるかどうかだけが心配だと思います。 より複雑なソリューションが機能すれば、それは素晴らしいことです。

マッピング関数の存在を示すサブタイプのより一般的な概念を持つことは、一般的に実装するのが難しいようです。 次の例はルールを正しく解釈していますか？

（b）〜Aのすべての正当なパラメータ化T1、T2、...に対して、Aが次のような〜Bのパラメータ化S1、S2、...が存在します

F（A、B）=（number、B）のマッピングが与えられた場合、次の場合、XはYのサブタイプになります。

type X = ~<A,B> = {x : B};
type Y = ~<A,B> = A extends number ? {x: B} : never;

ただし、 X<string,number>はY<string,number>サブタイプにはなりません。

マッピングの_存在_が十分であるかどうかはわかりません。 〜Aと〜Bを関数とし、〜Bが〜Aに近似すること、または〜Aが〜Bのサブタイプであることを示したい場合、〜Aがaであるような関数〜Cがあることを示します。 （〜B。〜C）のサブタイプでは不十分だと思います（Cはマッパーです）。 私は_all_マッピングの場合でなければなりません。

function id1<A, ~P extends ~PromiseLike>(p : P<A>) : P<A>;

function id2<A, P extends Promise<A[]>>(p : P) : P {
    //ERROR - P does not extend PromiseLike<A>
    return id1(p);
}

私はこの例に完全には従いません、ここでエラーが発生しないようにする必要がありますか？ これらを読んだところ、 id1は、すべての_inputs_にPromiseLikeを与える関数Pによって構築された入力が必要であるということです。 id2は、PromiseをA []に適用するサブタイプでなければならない値について話しているのに対して。 id2タイプから、 id1に必要な情報を復元できるかどうかはわかりません。 私はあなたの主張を誤解しているかもしれないと思います。

これらのタイプは突然異なり、現在は同じです

繰り返しになりますが、私はあなたの主張を見逃しているかもしれませんが、それらがどのように同じであるかはわかりません。 型内でRegularNumberをGenericNumberに置き換えることはできません。後者に引数を指定する必要があります。

マッピングの存在で十分かどうかはわかりません。 〜Aと〜Bを関数とし、〜Bが〜Aに近似すること、または〜Aが〜Bのサブタイプであることを示したい場合、〜Aがaであるような関数〜Cがあることを示します。 （〜B。〜C）のサブタイプでは不十分だと思います（Cはマッパーです）。 私はすべてのマッピングに当てはまる必要があります。

ええ、あなたは正しいです、そしてあなたが提供した反例もそうです。 私は他の反例を見つけました。 まったく機能しません。

このスレッドとたくさんの返信を読み直しました。 私はあなたが多くの点で正しいと思います、そして私は間違った方法で問題を見てきました。 私が言いたいことを説明します。

制約を低くする必要があるまで、常に最高の種類の制約を想定すると、あいまいになることに同意するかどうかはわかりません。 これはアサーションではなく、他の例を示している場合は十分に公平です。

あいまいであるか、参照できなくなっています。 上記の例のように、 Fooの型コンストラクターは、型自体によって隠されているため、参照できなくなります。 ~Fooを書いたり、 Foo<*>や~<A>Foo<A>など、他のものと競合しないものを書いたりすれば、この種の問題は発生しません。

はい、エイリアスを定義することでそれを回避できますが、あまりきれいではありません。

type Foo2<T> = Foo<T>

私が言ったように、これが最も重要な懸念事項ではないと思います。

私はこの例に完全には従いません、ここでエラーが発生しないようにする必要がありますか？ 私がこれらを読んだのは、id1には、すべての入力に対してPromiseLikeを与える関数Pによって構築された入力が必要であるということです。 id2は、PromiseをA []に適用するサブタイプでなければならない値について話しているのに対して。 id2のタイプからid1に必要な情報を回復できるかどうかはわかりません。 私はあなたの主張を誤解しているかもしれないと思います。

それは正しい読み方です、ええ。 ただし、 P extends Promise<A[]>場合は、 id1など、 Promise<A[]>を受け入れる任意の場所に割り当てることができます。 これが現在の状況であり、サブタイピングの意味です。

もう避けられないと思います。

繰り返しになりますが、私はあなたの主張を見逃しているかもしれませんが、それらがどのように同じであるかはわかりません。 型内でRegularNumberをGenericNumberに置き換えることはできません。後者に引数を指定する必要があります。

私が意味したのはこれです：すべてのTのタイプGenericNumber<T>と、タイプRegularNumberは同一で交換可能です。 一方がチェックを入力し、もう一方が入力しないコンテキストはありません。 少なくとも今は。

私たちが話していることはそれらを違うものにするでしょう。 GenericNumber<T>はTCからのものであるため、 RegularNumberができない場所で

私はこれについて考えました、そしてそれは避けられないかもしれなくて、必ずしも悪いわけではないと思います。 ただ新しい、異なる振る舞い。

それについて考える1つの方法は、typeパラメーターがtypeの「構造」の一部になるということです。

TCはもっと異なる行動につながると思います。

新しい方向性

まず第一に、正しいサブタイプの関係はマッピングを持たない関係であるという点であなたは正しいと思います。

私の最初のアイデアは次のとおりでした。 ~Aが~Bサブタイプになる場合：

1. （a）それらは同じ種類でなければなりません（制約ではなく、アリティの観点から）。
2. （b） ~Aすべての正当なパラメーター化T₁, T₂, ...について、 A<T₁, T₂, ...>はB<T₁, T₂, ...>サブタイプでなければなりません。

マッピングのこと...正直なところ、それはかなり愚かです。 MyPromise<T> extends Promise<T[]>と~Promiseを統合する方法はもうないと思います。 誰かが他のことを考えているかどうか知りたいです。

また、このルールでも機能しない例がないかどうかも知りたいです。

型コンストラクターの制約がサブタイプの関係を使用して表現されることに同意する場合、これは非常にうまく機能しているように見えますが、他のことに移ることができます。

構文について

私たちはこの問題について実際には同意していないようです。 ~Promise似たプレフィックス構文を強く好みます。 概念的には、 ~は、「のTCへの参照」演算子などと見なすことができます。

私はそれが代替案よりも優れているいくつかの理由を挙げたと思います：

1. 完全に明白です。
   
   
   
   1. この構文に関連するエラーも明確です。 誰かが型をパラメータ化するのを忘れた場合、それらが何であるかを知らなくても、型コンストラクタに関するエラーは発生しません。
   
   
   2. 副作用として、既存のエラーテキストとロジックを変更する必要はありません。 誰かがPromise書き込んだ場合、エラーメッセージは現在とまったく同じになります。 TCについて話すために変更する必要はありません。
   
   
2. 構造構文にも拡張できます。
3. 解析しやすいと思います。 タイプが予期される場所に表示される~\wは、TCへの参照を示していると見なされます。
4. 入力が簡単です。

他の方にもご意見をいただければ幸いです。

和集合、共通部分、およびデフォルトの型パラメーターについて

* & (* => *) 、 * | (* => *)などのフォームのオーバーロード/混合の種類は合法ですか？ それらには興味深い用途がありますか？

それらは悪い考えであり、推論するのは難しいと思います。 また、 * | (* => *)を明確にして、そこから型を作成できるようにするために必要な型注釈の種類もわかりません。

このような種類が現在存在していると言える1つの方法は、デフォルトの型パラメーターを持つ型です。

type Example<A = number> = {}

この型は、型パラメータを受け入れて型を構築できるため、種類* & (* => *)あると言えますが、必ずしもそうする必要はありません。

デフォルトの型パラメーターは、型を説明する方法ではなく、省略形である必要があると思います。 したがって、タイプの種類を決定するときは、デフォルトのタイプパラメータを無視する必要があると思います。

ただし、 ~Promise | ~Arrayなどのタイプについて話すことは理にかなっている場合があります。 それらは同じ種類なので、互換性はありません。 これはサポートされる

対処しなければならないこと

次のような関連する状況に対処する必要があります。

type Example = (<~P extends ~Promise>() => P<number>) | (<~M extends ~Map>() => Map<string, number>);

しかし、これは実際には種類(* => *) | (*, *) => *含みませんが、何か別のものです

他のTCを構築していますか？

前に述べたように、 * => (* => *)ような他のTCを構築するTCを用意するのは良い考えではないと思います。 これらはカリー化などをサポートする言語では標準ですが、TypeScriptでは標準ではありません。

~構文とサブタイプの関係を使用してそのような型を定義することを私が見ることができる方法はまったくないので、それらを禁止するための特別な規則は必要ありません。 それらを機能させるには特別なルールが必要になります。

おそらく、次のように構造的に定義できると思います。

~<A>~<B>{a : A, b : B}

それが私が考える唯一の方法です。

上位の機能との相互作用？

型パラメーターを受け取る関数型との自然ではあるが複雑な相互作用があります。

type Example<T> = <~P extends ~Promise>(p : P<T>) : P<T>;

この相互作用を何らかの方法で停止する必要がありますか？ このようなタイプは非常に複雑になっていることがわかります。

一般的に、TCパラメータを表示してはいけない場所はありますか？

私の構造構文は良い考えですか？

すぐに実装する必要はないと思いますが、それでも私の構造構文は良い考えだと思います。 それはあなたを可能にします：

1. 制約では、他のタイプパラメータと同様にローカル識別子を使用します。
2. ~<A>Map<string, A> 、 ~<A, B>Map<B, A>などの非常に明示的で柔軟な方法で、型コンストラクターを部分的に適用します。
3. 型の他のすべての側面には構造構文があるため、TCにもそのような構文が必要です。

とは言うものの、TCはこれがなくても完全に機能する可能性があり、最初のPRではおそらくTCが関与しません。

条件付きタイプとの相互作用

機能は条件付きタイプでどのように機能しますか？ あなたはこれを行うことができるべきですか？

type Example<~P extends ~PromiseLike> = ~P extends ~Promise ? 0 : 1

自分自身は完全にはわかりません。 条件付き型はまだ完全に消化されていません。

過負荷の解決

これはやりづらい気がします。 さまざまな形式の過負荷解決によってさまざまなタイプが作成されるため、これは実際には非常に重要です。

とはいえ、今のところ良い例は思いつかない。

明確に定義された中間言語を使用してTypeScriptを開始点として記述した場合、これの多くは重要なポイントでした。 例：システムF <：またはSimplified DependentMLなどのサウンド依存型システムの1つ。

これが前に解決されたら正直驚かされる
https://github.com/Microsoft/TypeScript/issues/14833

＃17961はおそらくこれを間接的に解決できると思います。 詳細については、この要点を参照してください。

BifunctorとProfunctor型は、制約レベルでは少し複雑であることに注意してください。 infer Tではなく、明らかにユニバーサル型を使用する方がはるかに簡単です。 thisを「戻り値の型」（純粋に型レベル）として使用できれば、ほとんどのインターフェイスの定義が簡単になります。

（私はTSのヘビーユーザーではないので、間違いを犯した可能性があります。 @ tycho01それを見て、タイプの混乱のどこかで失敗したかどうかを確認してください。私が尋ねる理由は、あなたが後ろにいるからです。上記のPR、そして私はあなたの他の実験やユーティリティのいくつかを見てきました。）

@isiahmeadows @ tycho01うわー...

あなたが正しい。 私がそれを正しく理解すれば、それはほとんど同じ結果をもたらします。

いくつかの違いがあります。 しかし、機能的にはほとんど同じであり、これらの違いは解決できると思います。

正しい型関数を推測することはできません

function example<~P extends ~PromiseLike>(p : P<number>) : P<string>;

ここで、 ~Bluebirdからp ~Promiseと~Bluebirdを推測できます。 ただし、次のようにすると、次のようになります。

function example<F extends <T>(t: T) => PromiseLike<T>>(p : F(number)) : F(string)

私はこれがうまくいくかどうか非常に疑っています：

example(null as Promise<number>)

Fが次のように意図されていると推測する方法はありません。

<T>(t : T) => Promise<T>

この機能は特別なものとは見なされないためです。 一方、TCの場合、一部の型には基本的に「暗黙の」型レベルの機能があります。それはTCです。

既存のTCを簡単に参照することはできません

私の提案のように~Promise行うことはできません。 構造形式を使用して、型を直接エンコードする必要があります。

type PromiseTC = <T>() => Promise<T>

確かに、それは懸念事項です。 これは、既知の引数型から汎用関数自体を推論する機能が必要な型推論の問題です（通常発生するのとは逆です）。 ほとんどの場合に機能するのに十分一般的な方法で解決できますが、重要な新しい特殊なケースが必要です。

NoInfer<T>を戦略的に使用することで部分的に解決できるかもしれませんが、それをどのように行う必要があるのか​​、そして一般的なケースでさえどれだけ対処できるのか、100％確信はありません。

@GregRos

私は構文を強く支持していません。それは私の好みであり、 ~には多くのメリットがあります。 推論が常に可能であるとは限らないため、考慮すべき主なことは、明示的な種類の注釈の構文が必要かどうかだと思います。

マッピングのこと...正直なところ、それはかなり愚かです。 MyPromiseを統合する方法はないと思いますPromiseを拡張します

マッピングのことはまだ有用な概念だと思いますが、上記の場合、 ~MyPromiseを~Promiseと統合しようとするべきではないと思います。統合する必要があるものです。は~MyPromiseと~<T>Promise<T[]>であり、 ~(Promise . [])書くこともできます。 欠けていたのは、マッピングがサブタイプ関係の一部である必要があるということだと思います。それはPromiseと同じくらいコンストラクターの一部です。 この例では、マッピングは単なるリストコンストラクターです。

interface A<T> {
    x: T;
} 

interface B<T> {
    x: T[];
}

~<T>B<T>は~<T>A<T[]>拡張しますか？ はい。 ~<T>B<T>は~<T>A<T>拡張しますか？ いいえ。しかし、最終的には2つの無関係な質問です。

型コンストラクターの制約がサブタイプの関係を使用して表現されることに同意する場合、これは非常にうまく機能しているように見えますが、他のことに移ることができます。

はい、それは物事を説明する良い方法のように思えます。

正しい型関数を推測することはできません

function example<~P extends ~PromiseLike>(p : P<number>) : P<string>;
ここでは、pから~Promiseと~Bluebirdを推測できます。

これはアサーションではなく、型チェックがどのように機能するか完全にはわからないため、よりオープンな質問です。 上記のインターフェースA例として使用すると、タイプA<number>と{x: number}は区別できないため、コンストラクターを推測できるかどうかはわかりません。コンストラクターのアプリケーションから返された型から。 P<number>からPを回復することは可能でしょうか？ これをサポートするために物事が変更される可能性があると確信しています、私はそれが今何をしているのか疑問に思っています。

＃17961からのクロスレスポンスですが、残念ながら@isiahmeadowsのアプローチを機能させる方法が

したがって、入力Promise<number>またはBluebird<number>に基づいて、これらのタイプの未適用バージョンを推測して、たとえばstring再適用できるようにしたいようです。 でもそれは難しいですね。

入力型が構造的に同等のものではなくこのようなものであっても（構造的に型付けされた言語ですよね？）、たとえばBluebirdに2つのパラメータ型がある場合、この推論も曖昧になります。その時点で<string>型のparamアプリケーションはもはや意味をなさないかもしれません。
私はそこに良い解決策がわかりません。 （免責事項：ここでの議論は少し遅れています。）

@ tycho01人々がT明示的にインスタンス化した場合、これらの問題はすべて解消されますか？

とにかくすべての場合に推論を解決できるとは思えないので、それは合理的だと思います。

@ jack-williams：これまでのところ＃17961ではありませんが、ディスパッチに使用すると役立つと思います。

let arr = [1, 2, 3];
let inc = (n: number) => n + 1;
let c = arr.map(inc); // number[]
let map = <Functor extends { map: Function }, Fn extends Function>(x: Functor, f: Fn) => x['map'](f); // any on 2.7 :(
let e = map(arr, inc);

@ tycho01はい、メソッド呼び出しでTがインスタンス化されていないため、私の提案がひどいことに気づきました。

次のようなものは動作しますか？

interface TyCon<A> {
    C: <A>(x: A) => TyCon<A>
}

interface Functor<A> extends TyCon<A> {
    C: <A>(x: A) => Functor<A>;
    fmap<B>(this: this["C"](A), f: (x: A) => B): this["C"](B);
}

interface Option<A> extends Functor<A> {
    C: <A>(x: A) => Option<A>;
}

@ jack-williams問題は、動作がfp-tsのADT実装とどのように比較されるかということだと思いますが、これはうまくいくようです。 おそらくTyConもありません。

@ jack-williams @isiahmeadows ：

すでに$Call利用可能であるため、tryflowでアイデアを試しました。 私にとってはどういうわけか反応しなくなったようですが...

interface Functor<A> {
    C: <A>(x: A) => Functor<A>;
    fmap<B>(f: (x: A) => B): $Call<$ElementType<this, "C">, B>;
}
// this: $Call<$ElementType<this, "C">, A>, 
// ^ flow doesn't seem to do `this` params

interface Option<A> extends Functor<A> {
    C: <A>(x: A) => Option<A>;
}

let o: Option<string>;
let f: (s: string) => number;
let b = o.fmap(f);

@ tycho01 thisフローから$ElementTypeプロパティを取得することはできないと思います

@ tycho01実際にはこれをtypescriptでも機能させることはできません
遊び場： https ：

@goodmind ：FunctorからMaybe fmapをコピーした後、 Functor<number> Maybe<number>ではなく
型呼び出しを使用すると、型の実行時実装が必要になるのではなく、型だけが存在するように改善されると思います。
さて、ファンクターはすでに独自のfmap実装を必要とします。 しかし、それは派生メソッドにとっては最悪です。
振り出しに戻って。 ：/

https://github.com/SimonMeskens/TypeProps/issues/1でいくつかの関連するアイデア

アルファ版をできるだけ早くリリースする予定ですが、その号の例を書いている私と一緒にフォローして、すでにその感触をつかむことができます。

この特定の問題を完全に解決するには少し時間がかかりますが、私が探しているのは単純な内容ですが、パラメーター化された汎用型がないために入力できないコードの実際の例です。 私はそれらのほとんどを入力できると思います（抽象リフト型コンストラクターに依存しない場合）。 上記のリポジトリでコードを使用して問題を自由に開いてください。可能であれば、入力します（または、ここに投稿することもできます）。

ヘッズアップ私は＃23809でこれを実装する試みを始めました。 まだ非常に不完全ですが、興味があればチェックしてください。

私はあなたたちに簡単な例を約束しました、ここにあります。 これは、ライブラリの作成から学んだいくつかのトリックを使用しています。

type unknown = {} | null | undefined;

// Functor
interface StaticFunctor<G> {
    map<F extends Generic<G>, U>(
        transform: (a: Parameters<F>[0]) => U,
        mappable: F
    ): Generic<F, [U]>;
}

// Examples
const arrayFunctor: StaticFunctor<any[]> = {
    map: <A, B>(fn: (a: A) => B, fa: A[]): B[] => {
        return fa.map(fn);
    }
};
const objectFunctor: StaticFunctor<object> = {
    map: <A, B>(fn: (a: A) => B, fa: A): B => {
        return fn(fa);
    }
};
const nullableFunctor: StaticFunctor<object | null | undefined> = {
    map: <A, B>(
        fn: (a: A) => B,
        fa: A | null | undefined
    ): B | null | undefined => {
        return fa != undefined ? fn(fa) : fa;
    }
};

const doubler = (x: number) => x * 2;

const xs = arrayFunctor.map(doubler, [4, 2]); // xs: number[]
const x = objectFunctor.map(doubler, 42); // x: number
const xNull = nullableFunctor.map(doubler, null); // xNull: null
const xSome = nullableFunctor.map(doubler, 4 as number | undefined); // xSome: number | undefined

const functor: StaticFunctor<unknown | any[]> = {
    map(fn, fa) {
        return Array.isArray(fa)
            ? arrayFunctor.map(fn, fa)
            : fa != undefined
                ? objectFunctor.map(fn, fa)
                : nullableFunctor.map(fn, fa);
    }
};

const ys = functor.map(doubler, [4, 2]); // ys: number[]
const y = functor.map(doubler, 42); // y: number
const yNull = functor.map(doubler, null); // yNull: null
const ySome = functor.map(doubler, 42 as number | undefined); // ySome: number | undefined

// Plumbing
interface TypeProps<T = {}, Params extends ArrayLike<any> = never> {
    array: {
        infer: T extends Array<infer A> ? [A] : never;
        construct: Params[0][];
    };
    null: {
        infer: null extends T ? [never] : never;
        construct: null;
    };
    undefined: {
        infer: undefined extends T ? [never] : never;
        construct: undefined;
    };
    unfound: {
        infer: [NonNullable<T>];
        construct: Params[0];
    };
}

type Match<T> = T extends infer U
    ? ({} extends U ? any
        : TypeProps<U>[Exclude<keyof TypeProps, "unfound">]["infer"]) extends never
    ? "unfound"
    : {
        [Key in Exclude<keyof TypeProps, "unfound">]:
        TypeProps<T>[Key]["infer"] extends never
        ? never : Key
    }[Exclude<keyof TypeProps, "unfound">] : never;


type Parameters<T> = TypeProps<T>[Match<T>]["infer"];

type Generic<
    T,
    Params extends ArrayLike<any> = ArrayLike<any>,
    > = TypeProps<T, Params>[Match<T>]["construct"];

サンプルを更新して簡略化しました。ここにも遊び場のリンクがあります。
遊び場

上記のNPMライブラリを追加したので、簡単に操作できます。 私が適切なテストを受けるまで現在アルファ版ですが、HKTを書き込もうとしている皆さんの助けになるはずです。

Githubリンク

私は、条件付き型を使用して飽和型内の仮想型変数を置き換えることにより、HKTをシミュレートする簡単なアプローチで遊んでいます。

declare const index: unique symbol;

// A type for representing type variables
type _<N extends number = 0> = { [index]: N };

// Type application (substitutes type variables with types)
type $<T, S, N extends number = 0> =
  T extends _<N> ? S :
  T extends undefined | null | boolean | string | number ? T :
  T extends Array<infer A> ? $Array<A, S, N> :
  T extends (x: infer I) => infer O ? (x: $<I, S, N>) => $<O, S, N> :
  T extends object ? { [K in keyof T]: $<T[K], S, N> } :
  T;

interface $Array<T, S, N extends number> extends Array<$<T, S, N>> {}

// Let's declare some familiar type classes...

interface Functor<F> {
  map: <A, B>(fa: $<F, A>, f: (a: A) => B) => $<F, B>;
}

interface Monad<M> {
  pure: <A>(a: A) => $<M, A>;
  bind: <A, B>(ma: $<M, A>, f: (a: A) => $<M, B>) => $<M, B>;
}

interface MonadLib<M> extends Monad<M>, Functor<M> {
  join: <A>(mma: $<M, $<M, A>>) => $<M, A>;
  // sequence, etc...
}

const Monad = <M>({ pure, bind }: Monad<M>): MonadLib<M> => ({
  pure,
  bind,
  map: (ma, f) => bind(ma, a => pure(f(a))),
  join: mma => bind(mma, ma => ma),
});

// ... and an instance

type Maybe<A> = { tag: 'none' } | { tag: 'some'; value: A };
const none: Maybe<never> = { tag: 'none' };
const some = <A>(value: A): Maybe<A> => ({ tag: 'some', value });

const { map, join } = Monad<Maybe<_>>({
  pure: some,
  bind: (ma, f) => ma.tag === 'some' ? f(ma.value) : ma,
});

// Not sure why the `<number>` annotation is required here...
const result = map(join<number>(some(some(42))), n => n + 1);
expect(result).toEqual(some(43));

ここにプロジェクト： https ：

フィードバックを歓迎します！

@pelotom私はあなたのアプローチの構文の軽さが好きです。 このスレッドではまだ言及されていない他の2つのアプローチがあり、現在および将来のソリューションの作成方法に創造性をかき立てる可能性があります。 どちらもこの問題に対するオブジェクト指向のソリューションです。

1. Bertrand Meyerは、1988年の著書「オブジェクト指向ソフトウェア構築」でジェネリック型をシミュレートする方法について説明しました。

例はエッフェル塔にありますが、TypeScriptへの大まかな翻訳は次のようになります。

https://gist.github.com/mlhaufe/089004abd14ad8e7171e2a122198637f

中間クラス表現が必要なため、かなり重くなる可能性がありますが、クラスファクトリの形式またはTypeScript Mixinアプローチを使用すると、これを大幅に減らすことができます。

＃17588に適用できる場合があります

1. 2番目のアプローチは、オブジェクト代数（および抽象ファクトリ）をシミュレートするときに使用されます。

C<T>はApp<t,T>で表されます。ここで、 Tはクラスであり、 tはC関連付けられた一意のタグです。

interface App<C,T> {}

サンプル：

interface IApp<C,T> {}

interface IList<C> {
    Nil<T>(): IApp<C,T>
    Cons<T>(head: T, tail: IList<C>): IApp<C,T>
}

// defining data
abstract class List<T> implements IApp<typeof List, T> {
    // type-safe down-cast
    static prj<U>(app: IApp<typeof List, U>): List<U> { return app as List<U> }
}
class Nil<T> extends List<T> { }
class Cons<T> extends List<T> {
    constructor(readonly head: T, readonly tail: List<T>) {
        super()
    }
}

// The abstract factory where the HKT is needed
class ListFactory<T> implements IList<typeof List> {
    Nil<T>(): IApp<typeof List, T> { return new Nil() }
    Cons<T>(head: T, tail: IApp<typeof List, T>): IApp<typeof List, T> {
        return new Cons(head, tail)
    }
}

詳細と正当化については、次の論文のセクション3.5「型コンストラクターポリモーフィズムのエミュレート」を参照してください。

https://blog.acolyer.org/2015/08/13/streams-a-la-carte-extensible-pipelines-with-object-algebras/

@metaweta 、この問題の名前をHigher kinded types in TypeScriptして、Google検索からの視認性を高めることができますか？

おそらく、私たちの賢明で慈悲深いリポジトリメンテナ（たとえば、 @ RyanCavanaugh 、 @ DanielRosenwasser ）は、そのような変更が彼らの介入に値すると見なされる場合、タイトルを編集できますか？

これがコミュニティからバックログに移動したことの意味を知りたいです。 これはコアチームが現在より真剣に検討していることですか、それとも単にチームがこれは良いコミュニティ候補ではないと判断したことを意味しますか？

見つかった： 「コミュニティ」マイルストーンは「バックログ」マイルストーンを優先して非推奨になっているようです。したがって、この問題はおそらく現物で移行されました。

TSメンバーではなく、再マイルストーンされたリンクをクリックすることを決定した人だけです。

+1

これが私が構築しようとしていたもので、より種類の多いタイプの実際的なケースのようです。

同期または非同期で実行できるデータベースの抽象化を作成したいと思います。 コールバックを使用してそれをハックするのではなく、ジェネリックを使用したかったのです。 これが私がやりたいことです：

type Identity<T> = T

interface DatabaseStorage<Wrap<T> extends Promise<T> | Identity<T>> {
    get(key: string): Wrap<any>
    set(key: string, value: any): Wrap<void>
}

これは本当に強力です！

@ccorcosそれはMTLスタイルと呼ばれます。 fp-tsを使用した純粋な機能例については、 https：//github.com/gcanti/fp-ts/blob/master/tutorials/mtl.tsを参照して

@mlegenhausen申し訳ありませんが、その例に従うのに苦労しています。

fp-tsを掘り下げるときはいつでも、物事が非常に複雑になり、もろくなるのではないかと心配しています。 @pelotomの例はわかりやすいように見えますが...

これがTypeScriptに採用されない理由は何ですか？

@ccorcos IMHO fp-tsの例をお勧めしたとしても、MTL /タグレススタイルはまったくお勧めしません。 手動で管理する必要があるすべての効果的なモナドに抽象化レイヤーを追加すると、typescriptは使用するモナドを検出できず、これが複雑になります。 fp-tsコミュニティからわかるのは、1つの非同期モナド（ TaskEitherをお勧めします）を使用し、それを維持することです。 MTLの利点をテストする場合でも、テストしないコードで手間をかけるだけの価値はありません。 fp-ts基づくhyper-tsは、最近MTLのサポートを終了したライブラリの一例です。

興味深い... hyper-tsは本当にクールに見えます...

F-bounded polymorphismに基づいた軽量で種類の多いタイプのエンコーディングを思いつきました： https ：

このアプローチの利点は、型コンストラクターを型に関連付けるためにルックアップテーブル（単一の条件付き型または文字列キーを持つオブジェクト）を必要としないことです。 この手法は、タイプレベルのジェネリック関数のアプリケーションをエンコードするためにも使用できます（ ReturnType<<T>(value: T) => Array<T>>考えてください）。

それはまだ概念実証であるため、このアプローチの実行可能性に関するフィードバックは大歓迎です！

私はその@straxを見てみます、それは本当にクールに見えます！

一方、これが私たちが今できることのばかげた例です：

type Test1 = λ<Not, [True]>;        // False
type Test2 = λ<And, [True, False]>; // False
type Test3 = λ<And, [True, True]>;  // True

// Boolean

interface True extends Func {
    expression: Var<this, 0>;
}

interface False extends Func {
    expression: Var<this, 1>;
}

interface Not extends Func {
    expression: λ<Var<this, 0>, [False, True]>
}

interface And extends Func {
    expression: λ<Var<this, 0>, [Var<this, 1>, Var<this, 0>]>
}

// Plumbing

type Func = {
    variables: Func[];
    expression: unknown;
}

type Var<F extends Func, X extends number> = F["variables"][X];

type λ<Exp extends Func, Vars extends unknown[]> = (Exp & {
    variables: Vars;
})["expression"];

De Bruijnインデックスを追加したいのは、それはインターフェイスがもう必要ないことを意味するからですが、タプル計算が必要になると思います。それを避けようとしています。

提案

高階、ラムダ、参照型

タイプを参照として渡す

簡単に言えば、参照型または高階型を使用すると、型によって取得されたパラメーターを後で延期したり、型パラメーター（ジェネリック）を後で推測したりすることができます。 しかし、なぜ私たちは気にする必要がありますか？

型を参照として渡すことができる場合、それは、TypeScriptが型を評価することを決定するまで遅らせることができることを意味します。 実際の例を見てみましょう。

パイプでプレビュー

pipeジェネリック型を開発していると想像してください。 ほとんどの作業は、パイプされる関数が実際にパイプ可能であることを確認することです。そうでない場合、ユーザーにエラーが発生します。 そのためには、マップされた型を使用して、 pipe(...)ように関数の型をパイプします。

type  PipeSync<Fns  extends  Function[], K  extends  keyof  Fns> = 
    K  extends  '0'
    // If it's the first function, we leave it unchanged
    ?  Fns[K]
    // For all the other functions, we link input<-output
    : (arg:  Return<Fns[Pos<Prev<IterationOf<K & string>>>]>) =>
        Return<Fns[Pos<IterationOf<K & string>>]>;

ここで、マップされた型の関数に対してこれを繰り返す必要があります。

type  Piper<Fns  extends  Function[]> = {
    [K  in  keyof  Fns]:  PipeSync<Fns, K>
}

（完全な実装を参照してください）

これで、関数をパイプでつなぐことができ、TypeScriptは警告を出すことができます。

declare  function  pipe<Fns  extends  F.Function[]>(...args:  F.Piper<Fns>):  F.Pipe<Fns>

const  piped  =  pipe(
    (name:  string, age:  number) => ({name, age}),
    (info: {name:  string, age:  number}) =>  `Welcome, ${info.name}`,
    (message:  object) =>  false, // /!\ ERROR
)

できます！ 適切なエラーが発生しました：

タイプ '（メッセージ：オブジェクト）=>ブール値'の引数は、タイプ '（引数：文字列）=>ブール値'のパラメータに割り当てることができません。

問題

しかし問題がある。 これは単純な操作では非常にうまく機能しますが、渡した関数でジェネリック（テンプレート）を使い始めると完全に失敗することがわかります。

const  piped  =  pipe(
    (a:  string) =>  a,
    <B>(b:  B) =>  b, // any
    <C>(c:  C) =>  c, // any
)

type  piped  =  Piper<[
    (a:  string) =>  string,
    <B>(b:  B) =>  B,
    <C>(c:  C) =>  C,
]>
// [
//     (a:  string) =>  string,
//     (b:  string) =>  unknown,
//     (c:  unknown) => unknown
// ]

どちらの場合も、TypeScriptは関数タイプを追跡できませんでした。
>ここで高次タイプが登場します<

構文

type  PipeSync<Fns  extends  Function[], K  extends  keyof  Fns> = 
    K  extends  '0'
    // If it's the first function, we leave it unchanged
+   ?  *(Fns[K]) // this will preserve the generics
    // For all the other functions, we link input<-output
+   :  *( // <- Any type can be made a reference
+       <T>(arg:  T) => Return<*(Fns[Pos<IterationOf<K  &  string>>])>
+       // vvv It is now a reference, we can assign generics
+       )<Return<*(Fns[Pos<Prev<IterationOf<K  &  string>>>])>>
+       // ^^^ We also tell TS not to evaluate the previous return
+       // and this could be achieved by making it a reference too

つまり、 *てジェネリックを手動および動的に推測しました。 実際、 *を使用すると、ジェネリックの評価が延期されました。 したがって、 *動作は、コンテキストに応じて異なります。 *が次のタイプの場合：

• ジェネリックを受け取ることができる：
• はジェネリックそのものです：参照がわかるまで評価を延期します。 このために、参照ツリーは親から下に構築されます。 つまり、参照をネストできます。 これは、 T割り当てられたReturn<*(Fns[Pos<Prev<IterationOf<K & string>>>])>で上記で発生したこととまったく同じです。 この文脈では、 *即時の評価から「保護」していると言えます。
• 上記のいずれでもない：何もせず、同じタイプに解決されます

type  piped  =  Piper<[
    (a:  string) =>  string,
    <B>(b:  B) =>  B
    <C>(c:  C) =>  C
]>
// [
//     (a:  string) =>  string,
//     (b:  string) =>  string,
//     (c:  string) =>  string
// ]

したがって、TypeScriptは、ジェネリックが提供されている場合にのみ評価を開始/継続し、必要に応じて評価をブロックする必要があります（不完全なジェネリック）。 現時点では、TSはジェネリックをunknownタイプに変換することにより、ワンショットで評価します。 この提案では、何かが解決できない場合：

type  piped  =  Piper<[
    <A>(a:  A) =>  A, // ?
    <B>(b:  B) =>  B, // ?
    <C>(c:  C) =>  C, // ?
]>
// [
//     <A>(a:  A) =>  A,
//     (b:  A) =>  A,
//     (c:  A) =>  A
// ]

詳細

*は型への参照を取得し、そのジェネリックスの操作を可能にします。 したがって、型の前にワイルドカードを配置すると、その型への参照が取得されます。

*[type]

型への参照を取得すると、ジェネリックスの操作が自動的に有効になります。

*[type]<T0, T1, T2...>

ジェネリックは、可能であれば、ターゲットタイプによってのみ消費/設定されます。 だからこれを行う：

*string<object, null> // Will resolve to `string`

ただし、警告を表示するかどうかは、TypeScript自体で確認することもできます。 しかし、内部的には、TSはこれから何もするべきではありません。

また、 *を使用するのは良い考えだと思いました。これは、（C / C ++言語のように）何かへのポインターを象徴でき、TypeScriptに借用されていないためです。

高次タイプ

最も基本的な形式でどのように機能するかを見てきたので、コアコンセプトであるラムダタイプを紹介しJavaScriptのコールバック、ラムダ、参照と同様に、匿名型を使用できると便利です。

上記の例は、関数のジェネリックを引き継ぐ方法を示しています。 ただし、参照について話しているので、任意のタイプを*と組み合わせて使用​​できます。 簡単に言えば、型参照は、渡すことができるが、ジェネリックをまだ受け取っていない型です。

type  A<T  extends  string> = {0:  T}
type  B<T  extends  string> = [T]
type  C<T  extends  number> = 42

// Here's our lamda
type  Referer<*Ref<T  extends  string>, T  extends  string> =  Ref<T>
// Notice that `T` & `T` are not in conflict
// Because they're bound to their own scopes

type  testA  =  Referer<A, 'hi'> // {0: 'hi'}
type  testB  =  Referer<B, 'hi'> // ['hi']
type  testC  =  Referer<C, 'hi'> // ERROR

より高い種類のタイプ

interface Monad<*T<X extends any>> {
  map<A, B>(f: (a: A) => B): T<A> => T<B>;
  lift<A>(a: A): T<A>;
  join<A>(tta: T<T<A>>): T<A>;
}

検索ワード

上位＃order＃type #references #lambda #HKTs

@ pirix-ghほんの少しのメッセージを読むと、あなたが求めていることの多くがすでに可能であるか、すでに求められていることがわかります。

私はそれらを読みました。他の人と同じように（オールインワンソリューションの場合）、主に構文について自分のアイデアを要約できると思いました。

参照をチェーンする方法をよりよく説明するために上記の提案を編集し、 Pipeようなタイプがそれを処理する方法を修正しました（ロジックに関していくつかの間違いがありました）。

すべてのアップデート？

まだ更新はありませんか？ 私の意見では、この問題はTypeScriptがその潜在能力を最大限に発揮する上での最大の障害としてランク付けされています。 ライブラリを正しく入力しようとすると、長い苦労の末に諦め、この制限に再び直面したことに気付くことがよくあります。 それは普及しており、一見非常に単純なシナリオでも現れます。 すぐに対処されることを本当に望んでいます。

interface Monad<T<X>> {
    map1<A, B>(f: (a: A) => B): (something: A) => B;

    map<A, B>(f: (a: A) => B): (something: T<A>) => T<B>;

    lift<A>(a: A): T<A>;
    join<A>(tta: T<T<A>>): T<A>;
}

type sn = (tmp: string) => number

function MONAD(m: Monad<Set>,f:sn) {
    var w = m.map1(f);    // (method) Monad<Set>.map1<string, number>(f: (a: string) => number): (something: string) => number
    var w2 = m.map(f);    // (method) Monad<Set>.map<string, number>(f: (a: string) => number): (something: Set<string>) => Set<number>
    var q = m.lift(1);    // (method) Monad<Set>.lift<number>(a: number): Set<number>
    var a = new Set<Set<number>>();
    var w = m.join(q);    // (method) Monad<Set>.join<unknown>(tta: Set<Set<unknown>>): Set<unknown>.  You could see that typeParameter infer does not work for now.
    var w1 = m.join<number>(q);    // (method) Monad<Set>.join<number>(tta: Set<Set<number>>): Set<number>
}

quickinfoの修正、typeParameterの推測、エラーメッセージの追加、同じtypeConstructorの強調表示など、まだ多くの作業を行う必要があります。
しかし、それは機能し始めます、そしてこれが私が今のところ得ることができるものです。
インターフェースの例は@millsphttps ： //github.com/microsoft/TypeScript/issues/1213#issuecomment -523245130からのものであり、結論は本当に役に立ちます。そのおかげで素晴らしいです。

現在の方法がほとんどの状況で機能するかどうかを確認するために、コミュニティがそのようなユーザーケースをさらに提供できることを願っています。

また、HKT /関数型プログラミング/ラムダに関する情報を提供するのもよいでしょう（ lambdaと言うと、数学を意味します。数学を使わずに、ある言語で書かれた例しか見つかりませんでした）

これが私を大いに助けるものです：

• http://adriaanm.github.io/files/higher.pdf
  
  
  
  • このペーパーのBNFに従ってパーサーを変更します。
  
  

@ShuiRuTian m.join(q) Set<unknown> m.join(q)返すことに関して、 --noImplicitAnyが警告を発する原因になると思いますか？

現在の方法がほとんどの状況で機能するかどうかを確認するために、コミュニティがそのようなユーザーケースをさらに提供できることを願っています。

また、HKT /関数型プログラミング/ラムダに関する情報を提供するのもよいでしょう（ lambdaと言うと、数学を意味します。数学を使わずに、ある言語で書かれた例しか見つかりませんでした）

これ以上先に進まず、最近、一般的なカレーfilter関数を作成しようとしましたが、次のようなことをしたいと思いました。

const filterNumbers = filter(
    (item: number | string): item is number => typeof item === "number"
);

const array = ["foo", 1, 2, "bar"]; // (number | string)[]
const customObject = new CustomObject(); // CustomObject<number | string>

filterNumbers(array); // number[] inferred
filterNumbers(customObjectWithFilterFunction); // CustomObject<number> inferred

そして、実際にそれを行う方法はありません。TypeScriptに「受け取ったのと同じ型を返すが、この他のパラメーターを使用する」ように指示する方法が必要だからです。 このようなもの：

const filter = <Item, FilteredItem>(predicate: (item: Item) => item is FilteredItem) =>
  <Filterable<~>>(source: Filterable<Item>): Filterable<FilteredItem> => source.filter(predicate);

@lukeshiruええ、基本的にこれはhttps://pursuit.purescript.org/packages/purescript-filterable/2.0.1/docs/Data.Filterable#v：filterです。
TypeScriptのHKTには他にも同様のユースケースがたくさんあります。

@isiahmeadows試してみました。 あなたが正しいです。
@lukeshiruと@raveclassicありがとう！ この機能はかなり共鳴しているようです。 https://gcanti.github.io/fp-ts/learning-resources/を読んだ後、これを見てみ

行き詰まっていて、現在の⸘回避策‽が何であるかわかりません...
私はチェーン仕様を実装しようとしています：

m['fantasy-land/chain'](f)

Chain仕様を実装する値は、Apply仕様も実装する必要があります。

a['fantasy-land/ap'](b)

FunctorSimplexを実行し、それをFunctorComplex拡張し、次にApply拡張しましたが、 ApplyをChainとして拡張したいと思います。

だから私はそれが必要です（下の画像とコードへのリンク）：

（12行目でApplyが「ハードコード」されていないが一般的であるように、タイプをApTypeに渡す必要があります... IApplyから拡張されたタイプも取得します

7ff8b9cのコードスニペット

`` `typescript
エクスポートタイプApType = （ ap：適用<（val：A）=> B>、 ）=> IApply ;

/ * [...] * /

エクスポートインターフェイスIApplyはFunctorComplexを{
/ ** Fantasy-land/ap :: Apply f => f a ~> f (a -> b) -> f b * /
ap：ApType ;
}
`` `

スタックオーバーフローの質問への参照： TypeScriptジェネリックタイプの問題：回避策が必要