これが私が常に最新の状態に保つように努力する一種の実施計画です。

• []ステップ1：ASTにサポートを追加してきれいに印刷する
  
  
  
  • おそらく最初のステップは、新しいフォームの解析を開始し、それらのサポートをASTに追加することです。
  
  
  • ここでより詳細な考えについては、このコメントを参照してください。
  
  
  • いくつかの解析のみのテストを記述し、プリティプリンターのhirもテストできるはずです。
  
  
  • HIRの低下に到達すると、GATが存在する場合はエラーになる可能性があります
  
  
  • フィーチャーゲートを行うこともできます
  
  
• []もっと来る

まず、ASTについて詳しく説明します。 まず、今日それがどのように機能するかについて説明しましょう：

トレイト定義のtype Foo: Bar [= Baz];アイテムは、このASTバリアントによって定義されます。 これには、境界（ Bar ）と（オプションの）デフォルト値Bazが含まれます。 名前はTraitItem構造体で定義されています。

トレイトimplのtype Foo = Bar;アイテムは、このASTバリアントによって定義されます。 FooなどがImplItemで定義されているため、タイプBarのみが含まれます。 ImplItem struct 。

メソッドはすでに汎用化できるため、興味深いケースです。 これらのジェネリックパラメーターは、 MethodSig構造体のフィールドGenericsで宣言されています。 これはGenerics構造体のインスタンスです。

私の考えでは、 GenericsをメソッドからTraitItem （およびImplItem ）に「リフト」して、すべての形式に等しく適用されるようにするのが最善の方法です。特性とimplアイテム。 今のところ、一般的な定数はサポートしないと思いますが、正直なところ、いずれにせよ、それらはおそらく私たちが行っている作業から外れるだけなので、小さな拡張になります。 今計画を立てれば、仕事はもっとうまくいくと思います。

おそらく、まともな最初のPRは、他のすべての既存の機能を同じに保ちながら、その変更を行うことです。 つまり、 GenericsをTraitItem （およびImplItem ）に追加し、$＃$ MethodSigから追加します。 非メソッドには空のGenericsを提供します。 既存のコードを処理し、必要に応じてジェネリックを配管して機能させます。

@nikomatsakisかっこいい！ どうもありがとう！ 私は昨夜実験を始めましたが、ASTについてのコメントであなたが指摘したのと同じ場所を見つけたことを誇りに思います。 ：smile：（rustcは初めてだったので、それを成果として数えます！）

ジェネリックをTraitItemに引き上げるとは思いませんでした。 私のアプローチは、 GenericsをTraitItemKind::Typeに入れることでした。これは、型宣言がすでに格納されている場所だからです。 あなたのアプローチも理にかなっているので、私はそれを実装することに取り組みます。 私はまだこのコードベースに完全に慣れていないので、あなたが提案したものよりも使用した場合の私のアプローチの落とし穴を知りたいと思います。 あなたの思考プロセスについての洞察を教えてください。 ：スマイリー：

これが私が行ったであろう変更です：

pub enum TraitItemKind {
    // Generics aren't supported here yet
    Const(P<Ty>, Option<P<Expr>>),
    // `Generics` is already a field in `MethodSig`
    Method(MethodSig, Option<P<Block>>),
    // Added `Generics` here:
    Type(Generics, TyParamBounds, Option<P<Ty>>),
    Macro(Mac),
}

編集：Gitterのnikomatsakisによる回答

それらをタイプすることの落とし穴に関して
それもうまくいくと思います
私がそれをするのを嫌がった理由
メソッドとタイプに対して（少なくとも理論的には）同じことを本当にやりたいということです
そして-私が言ったように-原則として、定数に対して同じことを行うことができなかった理由はわかりません
Genericsをタイプバリアントに移動するだけだと思います
それはおそらくうまくいくでしょうが、あなたが見てみると、今、私たちはしばしば「型/定数のために1つのこと、メソッドのために1つのこと」をしなければなりません。
だから私はコードがもっと均一になると思う
正直に言うとどうなるかよくわかりません=）-それは苦痛かもしれません
しかし、span_bugを挿入できるので、多くの場合、必要以上に一般的なものにすることはそれほど悪くありません。 今のところ不可能な場合に電話をかけます（そして後で私たちは周りに来てそれらを修正します）

わかった！ 次のステップは、パーサーを拡張することです。 ここにいくつかのヒントがあります。 特性アイテムから始めましょう。

このルーチンは、特性アイテムを解析します。 関連する型を処理するケースを拡張して、 type Foo<....> = ...; （おそらくwhere-clauses）のようなものも解析したいと思います。 （ <...>は、ASTに追加したばかりの「ジェネリック」です。）

現在、 parse_ty_paramを使用しています。これは、基本的にT: Fooなどを解析します。関連付けられた型宣言の文法が型パラメーターの文法と一致しなくなったため、これを停止する必要があります。 したがって、おそらくparse_trait_item_assoc_tyのようなものを追加したいと思うでしょう。 これはparse_ty_param()の一種のクローンとして開始できますが、ここでparse_generics()を呼び出すように変更する必要があります。 そのルーチンは、ジェネリック宣言（ <...> ）が存在する場合はそれを解析し、存在しない場合は空のジェネリックを返します。 次に、ここにparse where句の呼び出しを追加します。メソッドの解析時に発生する呼び出しでモデル化できます。結果は、前に解析したgenericsに格納されることに注意してください。

これが完了すると、いくつかの解析テストを追加できるようになります。 src/test/run-pass/rfc1598-generic-associated-types/のようなディレクトリを作成し、そこに正常に解析できると予想されるファイルを追加することで、これを実行します。 今のところ、それらは正しく機能しませんが、それは問題ではありません。 空のmain関数を追加するだけです。 次に、 src/test/ui/rfc1598-generic-associated-types/に解析してはならない例を追加することもできます（ UIテストの追加方法については、 COMPILER_TESTS.mdを参照してください）。

他の何か-安定したビルドでこのようなものを使用する人を避けるために、この時点でこの作業を機能ゲートする必要があります。 ここでforgeに機能ゲートを追加するためのいくつかの手順があります（最後のセクションを参照）。 feature_gate.rsの訪問者に$ visit_trait_itemとvisit_impl_itemを追加する必要があります; そのアイテムがメソッドではないが、空でないジェネリックが含まれている場合は、 gate_feature_postを呼び出すことができます（例）。

名前解決を設定するには、適切な「リブ」を配置するだけだと思います（名前解決機能は、スコープ内の名前のセットをリブに編成します。各リブは1つのバインディングレベルを表します）。 例：implの場合：

impl<A,B> Foo<B> for Vec<A> {
   fn bar<T,U>(x: ...) { 
       for y in ... {
       }
   }
}

次のリブがあります。

- <A,B> (from the impl)
   - <T,U> (from the `bar` method's generics)
      - `x` (from the parameter list)
          - `y` (from the let)

一般に、メソッドがどのように機能するかをモデル化することは悪い考えではありません。 ここで少し「将来の保証」を行うこともできると思います。

メソッドの型パラメーターをスコープに取り込むコードは次のとおりです（これは、トレイトで定義されたメソッド用です）。

https://github.com/rust-lang/rust/blob/a35a3abcda67a729edbb7d649dbc663c6feabd4c/src/librustc_resolve/lib.rs#L1890 -L1892

トレイトで定義されたtypeの場合、空の型パラメーターrib（ NoTypeParameters ）を追加するようにハードコーディングされています。

https://github.com/rust-lang/rust/blob/a35a3abcda67a729edbb7d649dbc663c6feabd4c/src/librustc_resolve/lib.rs#L1897 -L1901

ジェネリックスがすべてのtrait/implアイテムに配置されたので、おそらくtypeの処理を削除し、メソッド処理を抽出して、より高いレベルで発生するようにしたいと思います。 ジェネリックがないアイテム（たとえば、 const ）の場合、新しく導入されたリブは空であるため、無害である必要があります（私は願っています）。

その他の興味深い点：

• implitemメソッドが設定されている場所
• ここで、implsのtypeが設定されています

あなたはその考えを理解します。

@petrochenkov-正しいと思いますか？

@nikomatsakis

正しいですか？

すべてが正しく見えます。

次のステップ。 生涯の解決。

良くも悪くも、これは現在、他の名前解決とはまったく別のコードで行われています。 これは、HIRが構築された後に行われるためです。 ほぼ確実にこれは変更されますが、まだ変更されていません。

基本的な考え方は通常の名前解決と同じですが、「リブ」ではなく「スコープ」と呼ぶ点が異なります。 =）

この「レイトバウンド」ライフタイムの概念のために、いくつかの軽度の問題があります。 ただし、ここでは実際には関係ありません。ジェネリック関連タイプのすべてのライフタイムは「早期バインド」になります。これは一種の単純なケースです。 「レイトバウンド」ライフタイムは、メソッドが呼び出されるまで値が提供されないメソッドまたは関数で宣言されたライフタイムです。 ここではそれほど関連性がないため、ここでは詳しく説明しません。主なことは、他の名前解決とは異なり、他の種類の一般的なアイテムの場合とまったく同じモデルのメソッドをたどりたくないということです。ケース。

これがコードの例です。 これは、 impl 、 struct 、またはその他の非機能アイテムにアクセスするコードです。 これらの場合、GATの場合と同様に、基本的に、 Genericsのすべてのライフタイムパラメータをスコープに取り込み、それらを「早期バインド」ライフタイムにマッピングします。

https://github.com/rust-lang/rust/blob/ddaebe938b8eb1f5e17570ae8091743972e02bdd/src/librustc/middle/resolve_lifetime.rs#L370 -L388

最初にライフタイムのベクトルを作成し、それぞれに対してRegion::earlyを呼び出していることがわかります。

https://github.com/rust-lang/rust/blob/ddaebe938b8eb1f5e17570ae8091743972e02bdd/src/librustc/middle/resolve_lifetime.rs#L376 -L378

次に、 Scopeを作成します。 next_early_index変数は、スコープ内にあるアーリーバウンドライフタイムの数をカウントしているだけです。 このコードはアイテムに固有であるため、これは常に、この現在のアイテムで宣言されたアーリーバウンドライフタイムの数になります。 （後で、追加のライフタイムをスコープに追加する場合を検討します。これは、GATに必要なものです。）

https://github.com/rust-lang/rust/blob/ddaebe938b8eb1f5e17570ae8091743972e02bdd/src/librustc/middle/resolve_lifetime.rs#L379 -L384

最後に、 with()を呼び出します。 このメソッドは、スコープをスコープに取り込み、クロージャを呼び出します。 このクロージャ内でアクセスするすべてのライフタイムには、スコープ内にあると定義した名前が表示されます。

https://github.com/rust-lang/rust/blob/ddaebe938b8eb1f5e17570ae8091743972e02bdd/src/librustc/middle/resolve_lifetime.rs#L385 -L388

では、もう1つの例を見てみましょう。 このケースは「impl特性」をカバーします。 それが行っていることの詳細はそれほど重要ではありません（つまり、 impl Traitの脱糖自体を行う必要はありません）。 それは、いくつかの新しい初期のライフタイムをスコープにもたらしていると言えば十分です-それはまさに私たちがGATのためにやりたいことです。

https://github.com/rust-lang/rust/blob/ddaebe938b8eb1f5e17570ae8091743972e02bdd/src/librustc/middle/resolve_lifetime.rs#L482 -L501

いくつか強調しておきます。 まず、メソッドnext_early_indexは、次の割り当てられていないアーリーバウンドインデックスを返します。

https://github.com/rust-lang/rust/blob/ddaebe938b8eb1f5e17570ae8091743972e02bdd/src/librustc/middle/resolve_lifetime.rs#L488

それが出発点です。 次に、 Region::earlyを再度使用して、以下に対して解決される新しいアーリーバウンドライフタイム定義を作成します。

https://github.com/rust-lang/rust/blob/ddaebe938b8eb1f5e17570ae8091743972e02bdd/src/librustc/middle/resolve_lifetime.rs#L490 -L492

最後に、 withを再度呼び出すことで、これらをスコープに入れます。

https://github.com/rust-lang/rust/blob/ddaebe938b8eb1f5e17570ae8091743972e02bdd/src/librustc/middle/resolve_lifetime.rs#L494 -L501

OK、これらは2つの例です。 2番目のようなことをしたいと思います。 これら2つのメソッドの定義を変更する必要があります。

https://github.com/rust-lang/rust/blob/ddaebe938b8eb1f5e17570ae8091743972e02bdd/src/librustc/middle/resolve_lifetime.rs#L509

https://github.com/rust-lang/rust/blob/ddaebe938b8eb1f5e17570ae8091743972e02bdd/src/librustc/middle/resolve_lifetime.rs#L520

どちらも、関連するタイプについて、関連するジェネリックを処理する必要があります。 （他の場合には、ジェネリックが空であると主張する必要があります。）

それで、私は今日早くこれに飛びつきました。 私は正しい軌道に乗っていることを確認したいと思います：

• 実行する必要があるのは、マップにライフタイムを導入してから、trait / implアイテムをウォークすることだけでしたか？ チェックは機能しているようですが、わかりにくいですが（後述）...単純な（無制限の）場合にのみ機能している可能性があります。
• type parameters are not allowed on this typeエラーを修正するために、 qpath_to_tyとassociated_path_def_to_tyの型パラメーターの禁止を$＃$ librustc_typeck/astconv.rs $＃$に削除しました。 いくつかのチェックに置き換える必要があると思います。 また...
• typeckからクラッシュが発生しています。 （具体的には書き戻し）

typeckの失敗は、関連付けられた型を持たない値にジェネリックスを提供するため、 src/test/compile-fail/struct-path-associated-type.rsでトリガーされます。

私が物事を正しく読んでいるなら、少なくとも関連するジェネリックカウントが一致するチェックを追加する必要があります（それをどこで行うかを見つけようとしています...）、そしておそらくノードなどのタイプを追加するために他のチェックを行うこともできます。

それに取り組むつもりですが、私が正しい方向に進んでいるかどうかについての指針は高く評価されています。

こんにちは@brandonson！ 誰かがRustコンパイラをハッキングするのを思いとどまらせるのは嫌ですが、 @ sunjayはすでに同じものを積極的にハッキングしていて、最初からこの変更を追求していると思います。この変更も同様です（すでに開始されていると思います）。 この取り組みを並行化する明白な方法があるかどうかはわかりません（確かに可能ですが、少し前に手順を練り上げる必要があります）。

ただし、取り組むべきものを見つけることに興味がある場合は、このマイルストーンのバグのいくつかに取り組むことをお勧めしますか？ https://github.com/rust-lang/rust/issues/46472は話されていないようです、私はすぐにそこにいくつかのコメントを残すことを試みることができます。

確かに私は誰かのつま先を踏むつもりはありませんが、実際にさらなる進歩が起こっていることを示すものは何も見られませんでした（確かに次のステップに関するコメントはかなり最近のものですが）。 本当に、ここ数日でGATが数回欲しかったので、これを解決しようとし始めました。将来、NLLの作業を行う必要はありませんが、これは解決すべき事項のリストの上位にあります。この時点で。

@sunjay 、あなたがまだこれに積極的に取り組んでいる/計画しているなら、私に知らせてください-私にあなたの仕事を複製させても意味がありません。

こんにちは@brandonson 、あなたの熱意と助けてくれる意欲に感謝します。 :)私は確かにこれに積極的に取り組んでいます。 ニコと緊密に協力しながら、実装の各部分を段階的に進めてきました。

私はこれをできるだけ早く取り除くためにできる限りのことをします。 私もこの機能が本当に欲しいです！

進捗状況はどうですか？ =）毎晩<3でこれを試すのが待ちきれません

GATとconstジェネリックの断面はどのように機能するのでしょうか。また、まとめたときに提案の一部だったのでしょうか。

私が言っていることの例：

trait Foo {
    type Bar<const N>;
}

こんにちは@sunjayこれは非常に重要な機能だと思います。2018年のロードマップのコメントで頻繁に言及されました。 順調に進んでいますか？ あなたの仕事をありがとう！

これは、現時点で私の最も望ましい機能です。 これが優先事項になり、すぐに毎晩その道を見つけることを願っています！

そこで最近、学校などで忙しい@sunjayに会い、次のステップを考えてみました。 彼らと私はある時点で会い、全体的な実装戦略について話し合い、最終的に彼らのリポジトリにコミットし、インラインコメントをたくさん残しました。

今後最も理にかなっている戦略は2つあると思います。

• まず、さらにいくつかのテストを作成する必要があります。
• パーサーとシステムの他の「フロントエンド」ビットにはいくつかの既知の欠点があり、それらを列挙して修正する必要があります。 おそらくテストでもっと見つかるでしょう。
• その時点で、トレイトシステムを適切にハッキングする準備が整いました。
  
  
  
  • 一部の基盤はすでに構築されているため、これは主に「リファクタリング」タスクであることが望まれます。
  
  
  • しかし、私は詳細に書く必要があります、私が知っている計画の書面による説明はありません、そして私は今のところそれのための時間がありません。
  
  

まず、いくつかの命令re：testsを作成することから始めます。これは、テストの方がすぐに実行できるためです。今週の後半に、残りの設計がどのように機能するか、およびコードを現在の場所から取得する方法を記述します。今それが必要な場所に。

それは素晴らしいです ！！ これと他のすべての努力で@sunjayに幸運を祈ります。

最初のステップは、完全なテストスイートがあることを確認することです。 既存のテストは次の場所にあります。

src/test/ui/rfc1598-generic-associated-types

それらを見るだけで、実行する必要のある作業の一部をすでに確認できます。

• [] construct_with_other_type.rs -予期しないE0110エラーが発生します
• [x] empty_generics - type Bar<,>でエラーが発生することを確認し、問題ないようです
• [x] generic-associated-types-where.rs -適切な場所でwhere句を解析できることを確認します。問題ないようです。
• [] generic_associated_type_undeclared_lifetimes.rs -予期しないE0110エラーが発生します
• [] iterable.rs -予期しないE0110エラーが発生します
• [] pointer_family.rs -予期しないE0109エラーが発生します
• [] streaming_iterator.rs -予期しないE0110エラーが発生します

カバレッジが不足している場所

• []現在、「予想される使用法」のテストはあまりありません。つまり、成功するはずのテストです。
  
  
  
  • pointer_familyはその方向にあるようです
  
  
  • ある種のtrait Iterable { type Item; type Iter<'a>: Iterator<Item = &'a Self::Item>; }テストを期待します
  
  
• []生涯シャドウイングテスト-私たちは一般的に生涯シャドウイングを禁止しているので、これらは違法であるはずです：
  
  
  
  • trait Foo<'a> { type Item<'a>; }
  
  
  • impl<'a> Foo<'a> for &'a u32 { type Item<'a> = i32; }
  
  
• []「完全修飾」構文はテストされていないようです
  
  
  
  • たとえば、 pointer_familyテストにはSelf::Pointer<T>がありますが、 <Self as PointerFamily>::Pointer<T>はありません
  
  
• []GATに対する引数の数が間違っています。 たとえば、上記のIterableの定義が与えられた場合：
  
  
  
  • <T as Iterable>::Item -パラメータがまったくありませんか？ 悪い。
  
  
  • 一部の同等のコンテキストではライフタイムの削除を許可するため、一部のコンテキストではこれを受け入れる場合があることに注意してください。
    
    私はここでどちらの方向にも行くことができました。 このような場合は、明示的な'_を書くことをお勧めします。
  
  
  • <T as Iterable>::Item<'_> -正解です。
  
  
  • <T as Iterable>::Item<T> -タイプが多すぎます！
  
  
  • など、もちろんタイプと寿命の両方をとるテストがあるといいでしょう
  
  
• []関連するタイプのデフォルト？ trait Foo { type Bar<T, U = T> where T: PartialEq<U>; }
  
  
  
  • その場合、 SomeType::Bar<u32>はSomeType::Bar<u32,u32>に相当しますが、これを確認する必要があります。
  
  

予期しないE0110エラーの修正

エラーE0110はprohibit_type_paramsによって報告されます：

https://github.com/rust-lang/rust/blob/e65547d4fad0425d1db4f33a4d8134bf2cad939e/src/librustc_typeck/astconv.rs#L912

最初のステップは、それがどこから呼び出されているかを把握することです。 これを行うための私の好ましい方法は、ローカルビルドを取得し、 -Ztreat-err-as-bugをRUST_BACKTRACE=1と組み合わせて使用​​することです。 しかし、rustcはまだ構築中であるため、これらの結果を表示することはできません。 ：P代わりに、簡単なrg prohibit_type_paramsを実行しました。次に、疑わしいケースを1つ指摘します。

1つの呼び出しはassociated_path_def_to_tyからです：

https://github.com/rust-lang/rust/blob/e65547d4fad0425d1db4f33a4d8134bf2cad939e/src/librustc_typeck/astconv.rs#L791 -L803

コメントが示すように、これはSelf::Pointer<T>のようなパスのPointer<T>コンポーネントを解決するために呼び出されます（タイプパラメーターは、それらが接続されている名前とともに、パスセグメントの一部と見なされることに注意してください） ）。 GATが登場するまで、タイプパラメータはそこでは合法ではなかったため（たとえば、 T::Item ）、包括的な制限があります。

https://github.com/rust-lang/rust/blob/e65547d4fad0425d1db4f33a4d8134bf2cad939e/src/librustc_typeck/astconv.rs#L810

明らかにこれはしません。 その行を削除して、パラメータが指定されている場合はそれらが期待される数と一致することを確認する何らかのチェックに置き換える必要があります。 これを行うには、おそらくcreate_substs_for_ast_pathにあるものと同様のエラーチェックコードが必要です。 特にデフォルトでのアカウンティングのために、ここで共有コードを作成したいと思うかもしれません。実際にその関数を再利用できるでしょうか。

誰かがまだこれに取り組んでいますか？ これにはまだ長い道のりがあるように思えます。 GATは私の最も望ましいRFCです。 そうでない場合は、いくつかのテストに貢献したいと思います...

@rickyhanなので、 @ Centrilと@gaventoは、テスト作業を分割することについてWGの特徴について話していましたが、進展があったかどうかはわかりません。 チャイムを鳴らすことができるかもしれません。PRは大歓迎だと思います。 =）

私が愚かであるならば申し訳ありませんが、この種のことはGATで合法になるのでしょうか？

trait Sequencer {
    type Wrap<A>;
    fn chain<A, B, F>(Self::Wrap<A>, F) -> Self::Wrap<B>
        where F: FnOnce(A) -> Self::Wrap<B>;
    fn wrap<A>(A) -> Self::Wrap<A>;
}

これの状況はどうですか？ 私はチョークが最近ガットサポートを得たことを知っています。 それはすぐに錆びて着陸することを意図していますか？

@mark-im先週私はそれにショットを与えました。 私の理解では、構文パーサーはそこにあります（テストはありませんが）。 しかし、「実装」はまだ書かれていません。 （詳細については、https：//github.com/rust-lang/rust/issues/44265#issuecomment-330915766を参照してください）

@quadrupleslap AIUI、これは後で可能になりますが、最初は、GATは有効期間パラメーターのみをサポートします。

@Boscop RFCは、タイプパラメータもサポートされることを指定しています。

誰かがrustcの構文の実装の正確なステータスを知っていますか？ ほとんどがそこにあるように見えますが、ランクの高い境界はICEを生成します。
http://play.rust-lang.org/?gist=a48959858ed5dd432c2396feae5c3cc1&version=nightly&mode=debug

チョーク化作業を進めるには、少なくとも構文全体を実装する必要があります。 まだ構文に取り組んでいる人がいる場合は、私に知らせてください。そうしないと、自分で修正する可能性があります:)

私には、コミュニケーションがGATの実施を遅らせる大きな問題のように見えます。 これに取り組むことに興味を持っている人は少なくとも数人いるようですが、正確な実装状況と誰がすでにこれに取り組んでいるのかを実際に知っている人は誰もいません。 GATの実装について話すためだけに、Discord（またはIRC？）チャネルについてどう思いますか？ それは確かに役立つと思います。

また、私は確かにこれに取り組むために次の週の数営業日に貢献することができました（しかし私はまだコンパイラのこの部分について何も知りません）。

そこで、Discordの専用チャンネルをリクエストしました。 しかし、チャンネルを取得する代わりに、私はいくつかのことを学びました。 また、GATに関連するすべてのものを検索しました。 したがって、この機能に関するすべての情報を要約しようと思います。 多分それは何人かの人々に役立つでしょう。 でも何もわからないので、これを一粒の塩でどうぞ！ また、修正できるように、一部の情報が正しくない場合は教えてください。

GATに関する実施努力の要約

• @sunjayは2つの素晴らしいPRを上陸させました：

  • ジェネリック関連タイプの解析と名前解決（2017-12-02に統合）
  • ジェネリック関連タイプのライフタイム解決（2017-12-15に統合）

• その後、しばらくの間、多くは起こりませんでした。 その後、ニコはこのコメントでまだ何が必要かを要約しました（2018-03-12）。 基本的に、（a）書き込みテスト、（b）パーサー/フロントエンドのバグの修正/改善、および（c）トレイトシステムでの実装。 ポイント（a）は、このコメント（2018-03-13）でさらに説明されています。

• @gaventoがRFC1598（GAT）の拡張テストを開始しました（ 2018-05-11に統合）

  • テストに関するニコのコメントが、このPRで行われた変更をすでに反映しているかどうかはわかりません。 最新の編集は、@ gaventoがPRを開始した同じ日である2018-03-27からのものです。 （ @gaventoステータスについて教えていただけますか？）

それ以来、 UIテストは追加されていません。 また、GATに直接関連する他のPRは見つかりません。

ただし、上からのポイント（c）（形質システム）は「秘密裏に」取り組んでいます。 私が理解している限り、計画はすぐに新しいチョークベースの特性ソルバーに移行し、古いシステムでGATを機能させないことです。 新しい特性ソルバーの統合は、「チョーク化」追跡問題による追跡です。 チョークとチョーク化に関連するPRはかなりあります。 特に、 「FinishimplementingGATs」 （2018-05-24に統合）と呼ばれるチョークPRがあります。 したがって、GATのコアシステムはすでに整っているようです。

とは言うものの、チョークの「GAT」はプロトタイプの実装であり、rustcでそれを使用することは単なるuse chalk;ではありません。 @scalexmが私に言ったように、「[やるべきこと]はかなりたくさんあるようです」。

詳細と支援については、 #wg-traits Discordチャネルと特性WG追跡の問題を調べると役立つでしょう。

そのため、 @ nikomatsakisはrust-lang不和サーバーに#wg-traits-gatチャネルを作成しました（ここに参加してください）。 そこで助けたいと思っているすべての人を迎えることができれば素晴らしいと思います。 さらに、この機能のステータス（特に、まだ何をする必要があるのか​​、どこで支援できるのか）を知っている数人の人々。 これにより、特に、まだ深く関わっていない/特性WGの一部である私のような人々にとって、コミュニケーションがより簡単かつ迅速になるはずです:)

最近、これに関する更新はありますか？ Chalkがコンパイラに統合されるのを待っていますか？ （おそらく、そのための別の問題があります。）

おそらく、そのための別の問題があります。

48049

注（おそらく既知）と同様に、このコードはコンパイラーをパニックにします。

use typenum::{U1,U2,U3,Unsigned};

trait Array {
    type Of<Elem> ;
}

impl Array for U1 { type Of<T> = [T;1]; }
impl Array for U2 { type Of<T> = [T;2]; }
impl Array for U3 { type Of<T> = [T;3]; }

@wdanilo ：これはhttps://github.com/rust-lang/rust/issues/64755だと思います。

@varkor素晴らしい、ありがとう！

さらに別のメモ（ここでも、おそらく知られています）。 GATを設定すると、 &型と&mut型をうまく抽象化できるため、関数my_funcとmy_func_mutの間でコードを常にコピーして貼り付けるのをやめることができます。

#![feature(arbitrary_self_types)]
#![feature(generic_associated_types)]

use std::marker::PhantomData;

struct Pure <'t> (PhantomData<&'t()>);
struct Mut  <'t> (PhantomData<&'t()>);

type Ref<M, T> = <M as Acc>::Pat<T>;

trait Acc { type Pat<T: ?Sized>; }
impl<'t> Acc for Pure <'t> { type Pat<T> = PureRef <'t, T>; }
impl<'t> Acc for Mut  <'t> { type Pat<T> = MutRef  <'t, T>; }

struct PureRef <'t, T: ?Sized> (&'t     T);
struct MutRef  <'t, T: ?Sized> (&'t mut T);


/// USAGE ///

struct Buf<T> {
    data: Vec<T>
}

impl<T> Buf<T> {
    fn as_mut<M: Acc>(s: Ref<M, Self>) -> Ref<M, [f32]>
    {
        unimplemented!()
    }
}

ほとんどコンパイルされます。 GATなしで実装することもできますが、タイプは爆発します。

#![feature(arbitrary_self_types)]

use std::marker::PhantomData;
use std::ops::Deref;

struct Pure <'t> (PhantomData<&'t()>);
struct Mut  <'t> (PhantomData<&'t()>);

type Ref<M, T> = <M as Acc<T>>::Pat;

trait Acc<T: ?Sized> { type Pat; }
impl<'t, T: 't + ?Sized> Acc<T> for Pure <'t> { type Pat = PureRef <'t, T>; }
impl<'t, T: 't + ?Sized> Acc<T> for Mut  <'t> { type Pat = MutRef  <'t, T>; }

struct PureRef <'t, T: ?Sized> (&'t     T);
struct MutRef  <'t, T: ?Sized> (&'t mut T);


/// USAGE ///

struct Buf<T> {
    data: Vec<T>
}

impl<T> Buf<T> {
    fn as_mut<M>(self: Ref<M, Self>) -> Ref<M, [f32]>
    where M: Acc<Self> + Acc<[f32]>,
          Ref<M, Self>: Deref<Target = Self>
    {
        unimplemented!()
    }
}

（これは実際にコンパイルされます）

おそらくこれはサポートの質問ですが、 RFCまたはここのコメントから完全に明確ではなかったので、このページに来る人がこの提案を理解するのに役立つかもしれないと思います：

毎晩1.41で、私は次のことを試しました。

pub trait MyTrait {
    type MyType<U>;

    fn f<U>(self, x : <Self as MyTrait>::MyType<U>);
}

そして、これはコンパイルに失敗し、エラーは「タイプ引数は許可されていません」 MyTypeです。

次に、疑わしいと思われる<U>を削除しましたが、試してみようと思いました。

pub trait MyTrait {
    type MyType<U>;

    fn f<U>(self, x : <Self as MyTrait>::MyType);
}

驚くべきことに、これはコンパイルされました。 しかし、私がimplを書いたとき：

impl MyTrait for u64 {
    type MyType<U> = U;

    fn f<U>(self, x : <Self as MyTrait>::MyType) -> <Self as MyTrait>::MyType {
        x;
    }
}

これはコンパイラをパニックにしました。

私の質問は次のとおりです。

1. この種のスキームは現在可能ですか？しかし、私はそれを間違っているだけですか？
2. 今それが不可能な場合、この提案の下でそれは可能になるでしょうか？
3. もしそうなら、私が毎晩これを行うことができるようなタイムラインのアイデアはありますか？

お時間を割いていただき、誠にありがとうございます。

@clintonmead最終的には可能になるはずですが、機能の実装はまだ完了していません（実際、コンパイラは、使用しようとするとクラッシュする可能性があることを警告しています！）。 タイムラインがわかりません。

おそらく、この機能の作業を再開するために統合が十分に進んでいるかどうかをチョークの人に確認する価値がありますか？

これは現在ブロックされています

• ＃30472
• ＃67509
• ＃67510
• ＃67512
• ＃67513

現在のブロッカーで問題の説明を更新できますか？

@DutchGhostによって発生したブロッキングの問題をさらに追加しました

これは、より種類の多いタイプのエミュレーションにおける主要なステップになります。

私はこのようなものを想像しています：

// the plug/unplug idea is from https://gist.github.com/edmundsmith/855fcf0cb35dd467c29a9350481f0ecf

trait Monad /* : Applicative (for pure/return, doesn't matter for this example) */ {
    // Self is like the "f a" in haskell

    /// extract the "a" from "f a"
    type Unplug;

    /// exchange the "a" in "f a" in the type of Self with B
    type Plug<B>: Monad;

    fn bind<B, F>(this: Self, f: F) -> Self::Plug<B>
    where
        F: Fn(Self::Unplug) -> Self::Plug<B>;
}

impl<A> Monad for Option<A> {
    type Unplug = A;
    type Plug<B> = Option<B>;
    fn bind<B, F>(this: Self, f: F) -> Option<B>
    where
        F: Fn(A) -> Option<B> {
        this.and_then(f)
    }
}

提案された実装に関する質問：

私はこのような特徴を持っています

trait TradeableResource{
}

とこのような実装者

struct Food(f64);
impl TradeableResource for Food{}

私の特性のすべての実装者を「ニュータイプ」（f64をラップする単一要素のタプル構造体）に制限できるようにしたいと思います。

提案された実装をここで検討することで、それは可能でしょうか？

以下は確かに少し奇妙に見えますが、うまくいけば私がやりたいことを示しています。

trait TradeableResource{
    type Wrapper<T>:T(f64)
}

@ChechyLevasは、私が知る限り、これはGADTの範囲内ではありません。

しかし、あなたがやりたいことは、私が集めることができるものから、それがニュータイプであるという保証をあきらめ、代わりにそれぞれ内部値をラップして取得する関数を必要とする場合、最初にGADTを必要としません。 それほど便利ではありませんが、おそらく十分に機能するはずです。

したがって、次のことができます。

trait Traceable resource: From<f64> + Into<f64> { }

（これには、双方向でFromも実装する必要があります。これは、マクロを介して行います）

現状を少し感じてみたいと思います。 私は非同期の特性と生涯で少し遊んでいます。
私がやりたかったことの1つは、関連するReadAt: Futureタイプでtrait ReadAt<'r>を作成することでした。 これは、特性オブジェクトを使用する場合を除いて、多くの場合に機能します。

主な理由は、次のことを行うと、一般的ではないライフタイムをRにアタッチする必要があるためです。

impl<'a, 'r, R> ReadAt<'r> for &'a dyn for<'z> ReadAt<'z, ReadAt = R> + 'a {
    type ReadAt = R; // cannot have an `impl<R<'lifetime>>`
    ...
}

したがって、これはGATで解決できるかもしれないと思いましたが、トレイトオブジェクトでは関連する型を書き出す必要があるため、構文の魔法が再び必要になるという同様の問題が発生しました。

お気に入り：

trait ReadAt {
    type ReadAt<'r>: Future<Output = io::Result<usize>>;

    fn read_at<'a>(&'a self, buf: &'a mut [u8], at: u64) -> Self::ReadAt<'a>;
}

impl<'d> ReadAt for &'d (dyn ReadAt<HERE> + 'd) {
}

HEREにライフタイムを含める方法が必要です。 たとえば、これは受け入れられますが、 Rは具体的すぎるため、IMOでは不十分です。

impl<'d, R> ReadAt for &'d (dyn ReadAt<ReadAt = R> + 'd) {
    type ReadAt<'r> = R;

    fn read_at<'a>(&'a self, buf: &'a mut [u8], at: u64) -> Self::ReadAt<'a> {
        (**self).read_at(buf, at)
    }
}

しかし、これが特性オブジェクトに変換する方法がわからないため、それがとにかく機能するかどうかを実際にテストすることはできません。次のスニペットにライフタイムを取得する方法がわからないためです。

struct Test<T: ReadAt>(T);

impl<T: ReadAt> Test<T> {
    fn into_trait_object<'a>(&'a self) -> Test<&'a dyn ReadAt<ReadAt = T::ReadAt>> {
        todo!();
    }
}

T::ReadAtは私が提供できない寿命を要するので、これはdyn ReadAt<ReadAt<'r> = T::ReadAt<'r>>の構文拡張を見逃します。 （または、ライフタイムパラメータIMOを一致させるために、上記のスニペットが機能する可能性があります;-)）

タイプパラメータではなくライフタイムパラメータのみを使用しているので、ライフタイムパラメータがvtablesとタイプサイズに何らかの影響を与える可能性がない限り、これは技術的に可能であると思いますか？

@jendrikwコードはコンパイルされ、最新のnightly（1.46）で実行されます。 カスタムタイプなどでいくつかのテストを行いましたが、詳細を確認するためのfpの知識が不足しています。

今日、私は、おそらく生涯が十分に一般的ではないと思った何かのためにGATを使用しようとしました（動作するコードが続きます;完全なコードファイル）：

/// Helper trait for "stripping indention" from an object reference
pub trait AsUnindented<'ast> {
    type Output;

    /// Returns a reference to the unindented part of `Self`
    fn as_unindented(&'ast self) -> Self::Output;
}

impl<'ast, T: 'ast> AsUnindented<'ast> for Indented<T> {
    type Output = &'ast T;

    #[inline]
    fn as_unindented(&'ast self) -> &'ast T {
        &self.data
    }
}

impl<'ast, T: 'ast> AsUnindented<'ast> for crate::Block<T>
where
    T: AsUnindented<'ast> + 'ast,
{
    type Output = crate::View<'ast, T, fn(&'ast T) -> T::Output>;

    #[inline]
    fn as_unindented(&'ast self) -> Self::Output {
        crate::View::new(self, T::as_unindented)
    }
}

次に、次のコードでGATを使用してみました。

pub trait AsUnindented {
    type Output<'ast>;

    /// Returns a reference to the unindented part of `Self`
    fn as_unindented<'ast>(&'ast self) -> Self::Output<'ast>;
}

impl<T> AsUnindented for Indented<T> {
    type Output<'ast> = &'ast T;

    #[inline]
    fn as_unindented<'ast>(&'ast self) -> &'ast T {
        &self.data
    }
}

impl<T> AsUnindented for crate::Block<T>
where
    T: AsUnindented,
{
    type Output<'ast> = crate::View<'ast, T, fn(&'ast T) -> T::Output<'ast>>;

    #[inline]
    fn as_unindented<'ast>(&'ast self) -> Self::Output<'ast> {
        crate::View::new(self, T::as_unindented)
    }
}

それはうまくいきません。 両方のトレイト実装でE0309 （ the parameter type 'T' may not live long enough ）で失敗します。 これを修正する方法や、誤解があるかどうかはわかりません。 コンパイラーは、 implレベルでTに境界をアタッチすることを望んでいますが、そのレベルでは、ライフタイム'astはなく、 T: 'staticを制約したくありません。 for<'ast> T: 'astのようなものは機能しません）。

編集：コードベースの別の部分にGATを適用しようとしましたが、（今のところ）1つのエラーしかスローされませんが、前述の問題の修正に依存するため、単純に修正することはできません。

アウトライフバウンドは、関連付けられたタイプに追加できます（トレイトのバージョンでSelf: 'astを使用）。 このテストは、これがどのように見えるかを示しています。
https://github.com/rust-lang/rust/blob/db4826dd6ca48663a0b4c5ab0681258999017c7d/src/test/ui/generic-located-types/iterable.rs#L6 -L21

まあ、それは部分的にしか機能しません...

error[E0309]: the parameter type `T` may not live long enough
  --> src/indention.rs:33:5
   |
33 |     type Output<'ast> where T: 'ast = &'ast T;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = help: consider adding an explicit lifetime bound `T: 'ast`...
   = note: ...so that the type `T` will meet its required lifetime bounds

error[E0309]: the parameter type `T` may not live long enough
  --> src/indention.rs:45:5
   |
45 |     type Output<'ast> where T: 'ast = crate::View<'ast, T, fn(&'ast T) -> T::Output<'ast>>;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = help: consider adding an explicit lifetime bound `T: 'ast`...
   = note: ...so that the type `T` will meet its required lifetime bounds

error[E0309]: the parameter type `T` may not live long enough
  --> src/indention.rs:59:5
   |
59 | /     type Output<'ast2>
60 | |         where
61 | |             T: 'ast2,
62 | |             O: 'ast2
63 | |         = crate::View<'ast2, T, crate::view::MapViewFn<F, fn(F::Output<'ast2>) -> O::Output<'ast2>>>;
   | |_____________________________________________________________________________________________________^
   |
   = help: consider adding an explicit lifetime bound `T: 'ast2`...
   = note: ...so that the type `T` will meet its required lifetime bounds

error[E0309]: the parameter type `O` may not live long enough
  --> src/indention.rs:59:5
   |
59 | /     type Output<'ast2>
60 | |         where
61 | |             T: 'ast2,
62 | |             O: 'ast2
63 | |         = crate::View<'ast2, T, crate::view::MapViewFn<F, fn(F::Output<'ast2>) -> O::Output<'ast2>>>;
   | |_____________________________________________________________________________________________________^
   |
   = help: consider adding an explicit lifetime bound `O: 'ast2`...
   = note: ...so that the type `O` will meet its required lifetime bounds

コードが1つのステージを通過すると（以前は同様のエラーでエラーが発生しましたが、それらの間に、 E0107 sのみで構成される別のカテゴリのエラーが表示されました）hm。

編集：最初のステートメント（ where Self: 'ast ）を見逃しました。 その部分は現在修正されています。 続けてみます。

わかりました、次のスニペット：

impl<'ast, T, F, O> AsUnindented for crate::View<'ast, T, F>
where
    Self: Clone,
    F: crate::view::ViewFn<T, Output = &'ast O>,
    O: AsUnindented + 'ast,
{
    type Output<'ast2>
        where
            T: 'ast2,
        = crate::View<'ast, T, crate::view::MapViewFn<F, fn(&'ast O) -> O::Output<'ast>>>;

    #[inline]
    fn as_unindented<'ast2>(&'ast2 self) -> Self::Output<'ast2> {
        self.clone().map::<for<'x> fn(&'x O) -> O::Output<'x>, _>(O::as_unindented)
    }
}

エラー：

error[E0631]: type mismatch in function arguments
  --> src/indention.rs:66:67
   |
66 |         self.clone().map::<for<'x> fn(&'x O) -> O::Output<'x>, _>(O::as_unindented)
   |                                                                   ^^^^^^^^^^^^^^^^
   |                                                                   |
   |                                                                   expected signature of `for<'x> fn(<F as view::ViewFn<T>>::Output<'x>) -> _`
   |                                                                   found signature of `for<'x> fn(&'x O) -> _`

<F as view::ViewFn<T>>::Output<'x> ==> &'ast Oと&'x Oが等しくないことは知っていますが、それを修正する方法がわかりません（コンパイラーはバインドされたF: for<'x> crate::view::ViewFn<T, Output = &'x O>を受け入れません）。
他の試行エラー：

error[E0582]: binding for associated type `Output` references lifetime `'x`, which does not appear in the trait input types
  --> src/indention.rs:56:39
   |
56 |     F: for<'x> crate::view::ViewFn<T, Output = &'x O>,
   |                                       ^^^^^^^^^^^^^^

トレイト出力タイプの割り当てでforall<'x>バウンドを表現する方法がわかりません。

where
    F: crate::view::ViewFn<T, for<'x> Output<'x> = &'x O>,

解析すらしません（「 + 、 , 、 :: 、または>のいずれかが見つかり、 =が見つかりました」）。

67510トラックがその境界を書き込むことができます。 その例では、遅延正規化も必要になる場合があります（＃60471）。

self.clone().mapの特性出力タイプは、実際にはO::as_unindentedのタイプ、つまりマップの引数タイプですか？
crate::Viewが何であるかはわかりませんが、 map関数は別の引数を予期する可能性があるため、型が一致しません。

@sighoya以前の投稿でリポジトリをリンクしました。これは、 crate::view::ViewFn::mapの実装への直接リンクです。

コンパイラはこれについて何と言っていますか？：

where
    for<'x> F: crate::view::ViewFn<T, Output<'x> = &'x O>,

（まだ）解析しません。

@matthewjasper 、

Rust Nomiconから、次の構文解析が行われます。

where for<'a> F: Fn(&'a (u8, u16)) -> &'a u8,

解析されないのはOutput<'x> = &'x 0>を使用しているためですか？

はい、 Output<'x>=...はその位置では解析されません。

rustc 1.46.0-nightlyでコンパイルされなくなったcreate、 grdfがあります。 最近GATに関して何か変わったことはありますか？

そもそもそれを機能させるためにトリックを使わなければならなかったので、私のケースは少し奇妙です。 私は本質的に、関連するイテレータタイプを持つGraph特性を持っています。 それを機能させるために、私はすべてのイテレータを別の特性Iterに配置しました：

pub trait Iter<'a, T: 'a> {
    type Triples: Iterator<Item = Triple<&'a T>>;
    type Subjects: Iterator<Item = (&'a T, Self::Predicates)>;
    type Predicates: Iterator<Item = (&'a T, Self::Objects)>;
    type Objects: Iterator<Item = &'a T>;
}

pub trait Graph<T = crate::Term> {
    /// Iterators.
    type Iter<'a>: Iter<'a, T>;

    ...
}

今までうまく機能したGraphの実装が1つあります。

impl<'a, T: 'a + Hash + Eq> crate::Iter<'a, T> for Iterators {
    type Objects = Objects<'a, T>;
    type Predicates = Predicates<'a, T>;
    type Subjects = Subjects<'a, T>;
    type Triples = Iter<'a, T>;
}

impl<T: Hash + Eq> crate::Graph<T> for HashGraph<T> {
    type Iter<'a> = Iterators;

    ...
}

rustcを更新したので、次のように失敗します。

error[E0309]: the parameter type `T` may not live long enough
  --> src/hash_dataset.rs:50:2
   |
50 |     type Iter<'a> = Iterators;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = help: consider adding an explicit lifetime bound `T: 'a`...
   = note: ...so that the type `T` will meet its required lifetime bounds

TはすでにIterの'aにバインドされているので、これは私にはあまり意味がありません...

さて、 whereの境界を追加して、再び機能させました。
特性では：

type Iter<'a>: Iter<'a, T> where T: 'a;

および実装では：

type Iter<'a> where T: 'a = Iterators;

しかし、特に実装において、 where境界の正確なセマンティクスを理解するかどうかはわかりません（初めて見たとき）。 また、なぜ以前は機能していましたか。

編集：私は自分の厄介なハックを削除し、関連するイテレータをトレイト自体に入れることさえできました。

@DutchGhostによって発生したブロッキングの問題をさらに追加しました

https://github.com/rust-lang/rust/issues/74684も追加できます:)

書きたくないので、急いで投稿してください。でも、この機能はもう3年近く停滞していて、最も望まれている新機能のひとつだと思います。

これはどこにありますか？ ここでの最新のステータスの概要は、 2018年6月の@LukasKalbertodtによるものです。 「チョーク化」を待っていますか？

素朴な観察：GATの私の望ましい使用法のほぼすべては、1つのライフタイムパラメーターのみを必要とします。 削減された生涯のみのバージョンのGATは、より簡単に提供できるでしょうか？

https://github.com/rust-lang/rust/issues/44265#issuecomment -568247656は（やや簡潔な）更新です。

67510は、実装が必要な最後の主要なICE/欠落機能です。

このRFCはMonadとFunctorを直接可能にしますか？ それとも、HKTで実行する必要のある作業が他にありますか？

このRFCは、MonadとFunctorを直接可能にしますか？ それとも、HKTで実行する必要のある作業が他にありますか？

@ibraheemdevRFCは述べています

これは、人々がより高い種類のタイプについて話すときに必要なすべての機能を追加するわけではありません。 たとえば、モナドのような特性は有効になりません。 これらの機能をすべて一度に一緒に実装することを好む人もいます。 ただし、この機能は他の種類の高種類のポリモーフィズムと上位互換性があり、それらの実装を妨げるものではありません。 実際、部分適用など、他の種類のより高度なものにも影響を与えるいくつかの実装の詳細を解決することで、道を切り開きます。

@ibraheemdev ：モナドとファンクターを可能にする最も慣用的な方法は、ジェネリック関連の特性を導入することだと思いますが、ジェネリック関連の型は確かに前提条件です。

GATを必要としないMonadへのパスはありますか？

@ibraheemdev仮にそうです、HKTを直接実装してから、その上にMonadトレイトを実装することは可能です。 ただし、その方向で行われている作業はなく、おそらくそうなることはありません。そのアプローチでは、Rustの問題が実際には解決されないためです。https ：//twitter.com/withoutboats/status/1027702531361857536

たぶん私は間違っていますが、GATは次のようなものを許可すると思います

trait MonadFamily {
    type Monad<T>;
    fn pure<T>(inner: T) -> Self::Monad<T>;
    fn bind<T, U, F: FnOnce(T) -> U>(this: Self::Monad<T>, f: F) -> Self::Monad<U>;
}

@ibraheemdev

GATを必要としないMonadへのパスはありますか？

うん、Rustでより高種類のタイプをエミュレートする方法を参照してください。 今でも安定して動作します。