다음은 업데이트를 유지하기 위해 노력할 일종의 구현 계획입니다.

• [ ] 1단계: AST 및 pretty-printing에 지원 추가
  
  
  
  • 아마도 첫 번째 단계는 새 양식의 구문 분석 을 시작하고 AST에 대한 지원을 추가하는 것입니다.
  
  
  • 자세한 내용은 여기에서 이 댓글을 참조하세요 .
  
  
  • 우리는 구문 분석 전용 테스트를 작성할 수 있어야 하고 예쁜 프린터 hir도 테스트할 수 있어야 합니다.
  
  
  • HIR을 낮추면 GAT가 있으면 오류가 발생할 수 있습니다.
  
  
  • 기능 게이트를 수행할 수도 있습니다.
  
  
• [ ] 앞으로 더

AST에 대해 더 자세히 작성하는 것으로 시작하겠습니다. 먼저 오늘 작동 방식에 대해 논의해 보겠습니다.

특성 정의의 type Foo: Bar [= Baz]; 항목은 이 AST 변형 에 의해 정의됩니다. 여기에는 경계( Bar )와 (선택 사항) 기본값 Baz 가 포함됩니다. 이름은 TraitItem 구조체 에 정의되어 있습니다.

특성 impl의 type Foo = Bar; 항목은 이 AST 변형 에 의해 정의됩니다. Foo 등이 ImplItem 에 정의되어 있기 때문에 Bar 유형만 포함합니다. ImplItem 구조체 .

메소드는 이미 일반화될 수 있기 때문에 흥미로운 경우입니다. 이러한 일반 매개변수는 MethodSig 구조의 Generics 필드 에 선언됩니다. 이것은 Generics 구조체 의 인스턴스입니다.

내 생각에 가장 좋은 방법은 Generics 메서드 에서 TraitItem (및 ImplItem )로 "들어올려" 모든 형식에 동일하게 적용되도록 하는 것입니다. 특성 및 임프 항목. 지금으로서는 일반 상수를 지원하지 않을 것 같습니다. 하지만 솔직히 말해서 이 상수는 어떤 경우에도 우리가 하고 있는 작업에서 빠질 수 있으므로 작은 확장이 될 것입니다. 지금 계획만 하면 작업이 더 잘 될 것 같아요.

아마도 괜찮은 첫 번째 PR은 그 변경을 수행하고 다른 모든 기존 기능을 동일하게 유지하는 것입니다. 즉, Generics 를 TraitItem (및 ImplItem ) 및 MethodSig 에서 추가합니다. 메서드가 아닌 경우에는 빈 Generics 를 제공합니다. 우리는 기존 코드를 통해 작업하고 제네릭이 작동하도록 필요에 따라 연결합니다.

@nikomatsakis 멋지다! 정말 고맙습니다! 나는 어젯밤에 이것을 실험하기 시작했고 나는 당신이 AST에 대한 당신의 논평에서 지적한 것과 같은 곳을 찾았다는 것을 자랑스럽게 생각합니다. :smile: (rusc에서 처음 해보는거라서 성취감이 큽니다!)

제네릭을 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의 답변

그것들을 유형에 넣는 것의 함정에 관하여
나는 그것이 효과가 있을 수 있다고 생각한다
내가 그것을 꺼려했던 이유
방법과 유형에 대해 (적어도 이론상으로는) 동일한 작업을 수행하기를 정말로 원한다는 것입니다.
그리고 -- 내가 말했듯이 -- 원칙적으로 우리가 상수에 대해 같은 일을 할 수 없을 이유가 없다고 생각합니다.
제네릭을 유형 변형으로 옮기면
그것은 아마도 괜찮을 것입니다. 하지만 지금은 "유형/상수에 대해 한 가지, 메서드에 대해 한 가지"를 수행해야 하는 경우가 많습니다. 정확히 다르기 때문입니다.
그래서 나는 코드가 더 균일해질 것이라고 생각합니다.
솔직히 어떻게 될지 잘 모르겠습니다 =) -- 고통스러울 수 있습니다
하지만 필요한 것보다 더 일반적인 것을 갖는 것이 그렇게 나쁘지는 않은 경우가 많습니다. 왜냐하면 당신이 span_bug를 삽입할 수 있기 때문입니다! 지금은 불가능한 경우를 요청합니다(나중에 와서 패치합니다)

괜찮아! 다음 단계는 파서를 확장하는 것입니다. 다음은 몇 가지 팁입니다. 특성 항목부터 시작하겠습니다.

이 루틴은 특성 항목을 구문 분석합니다 . 우리는 type Foo<....> = ...; (어쩌면 where-clauses)와 같은 것들을 구문 분석하기 위해 연관된 유형을 처리하는 케이스 를 확장하고자 합니다. ( <...> 는 방금 AST에 추가한 "제네릭"입니다.)

현재 기본적으로 T: Foo 등과 같은 것을 구문 분석하는 parse_ty_param 를 사용하고 있습니다. 연관된 유형 선언의 문법이 더 이상 유형 매개변수의 문법과 일치하지 않기 때문에 이 작업을 중단해야 합니다. 따라서 parse_trait_item_assoc_ty 와 같은 것을 추가하고 싶을 것입니다. 이것은 parse_ty_param() 의 복제로 시작할 수 있지만 바로 여기에서 parse_generics() 를 호출 하도록 수정해야 합니다. 해당 루틴은 제네릭 선언( <...> )이 있으면 이를 구문 분석하고, 그렇지 않으면 빈 제네릭을 반환합니다. 그런 다음 바로 여기 에 where 절을 구문 분석하는 호출을 추가하고 싶습니다. 메서드를 구문 분석할 때 발생하는 호출을 모델링할 수 있습니다. 결과는 이전에 구문 분석한 generics 에 저장됩니다.

그렇게 하고 나면 몇 가지 구문 분석 테스트를 추가할 수 있어야 합니다. src/test/run-pass/rfc1598-generic-associated-types/ 와 같은 디렉토리를 만들고 거기에 성공적으로 구문 분석할 것으로 예상되는 파일을 추가하면 됩니다. 지금은 제대로 작동 하지 않지만 그것은 중요하지 않습니다. 빈 메인 함수를 추가하기만 하면 됩니다. 그런 다음 src/test/ui/rfc1598-generic-associated-types/ 로 구문 분석해서는 안 되는 예제를 추가할 수도 있습니다( UI 테스트 추가에 대한 지침은 COMPILER_TESTS.md 참조).

다른 것 -- 사람들이 안정적인 빌드에서 이 항목을 사용하지 않도록 이 시점에서 게이트 기능을 제공해야 합니다. 여기 forge에 기능 게이트를 추가 하기 위한 몇 가지 지침이 있습니다(마지막 섹션 참조). feature_gate.rs 의 방문자 에게 visit_trait_item 및 visit_impl_item 를 추가해야 합니다. 해당 항목이 메서드가 아니지만 비어 있지 않은 제네릭이 있는 경우 gate_feature_post ( 예제 )를 호출할 수 있습니다.

이름 확인을 설정하기 위해 우리가 해야 할 일은 적절한 "갈비뼈"를 제자리에 두는 것뿐이라고 생각 합니다(이름 확인 항목은 범위에 있는 이름 집합을 갈비뼈로 구성합니다. 각 갈비는 하나의 바인딩 수준을 나타냄). 예를 들어 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

이제 제네릭이 모든 특성/impl 항목에 배치되었으므로 type 에 대한 처리를 제거하고 더 높은 수준에서 발생하도록 메서드 처리를 추출하고 싶습니다. 제네릭이 없는 항목(예: const )의 경우 새로 도입된 리브는 비어 있어야 하므로 무해해야 합니다(희망합니다).

다른 관심 지점:

• impl 항목 방법이 설정되는 위치
• 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

자, 이제 예를 하나 더 살펴보겠습니다. 이 사례는 "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

좋습니다. 두 가지 예입니다. 우리는 두 번째 것과 비슷한 것을 하고 싶을 것입니다. 이 두 가지 방법의 정의를 수정하려고 합니다.

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

둘 다 연결된 유형에 대해 연결된 제네릭을 처리해야 합니다. (아마도 다른 경우에는 제네릭이 비어 있다고 주장해야 합니다.)

그래서 나는 오늘 일찍이 일에 뛰어 들었다. 올바른 방향으로 가고 있는지 확인하고 싶습니다.

• 지도에 수명을 소개한 다음 특성/impl 항목을 살펴보기만 하면 됩니다. 확인하기는 어렵지만(나중에 참조)... 간단한(무제한) 경우에만 작동할 수 있습니다.
• type parameters are not allowed on this type 오류를 수정하기 위해 librustc_typeck/astconv.rs qpath_to_ty 및 associated_path_def_to_ty 에 대한 유형 매개변수 금지를 삭제했습니다. 몇 가지 점검으로 교체해야 한다고 생각합니다. 또한...
• 지금 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 님 안녕하세요. 기꺼이 도와주셔서 감사합니다. :) 나는 실제로 이것에 대해 적극적으로 노력하고 있습니다. 저는 Niko와 긴밀히 협력하여 올바르게 구현하는 동안 구현의 각 부분을 단계별로 살펴보았습니다.

가능한 한 빨리 이 문제를 해결할 수 있도록 최선을 다하겠습니다. 저도 이 기능 정말 갖고 싶어요!

진행 상황은 어떻습니까? =) 야간 <3에서 이것을 실험하기를 기다릴 수 없습니다.

GAT와 const 제네릭의 횡단면이 어떻게 작동하는지, 그리고 함께 결합했을 때 제안서의 일부였는지 궁금합니다.

내가 의미하는 바의 예:

trait Foo {
    type Bar<const N>;
}

안녕하세요 @sunjay 저는 이것이 상당히 중요한 기능이라고 생각합니다. 2018 로드맵 댓글에서 많이 언급되었습니다. 어떻게 진행되고 있습니까? 작업해주셔서 감사합니다!

현재 가장 원하는 기능입니다. 이것이 우선 순위가 되어 곧 밤낮으로 진행되기를 바랍니다!

그래서 최근에 학교와 다른 일로 지금 바쁜 @sunjay 를 만나 여기에서 다음 단계를 계획하려고 합니다. 그들과 나는 어느 시점에서 만나 전반적인 구현 전략에 대해 논의했고, 그들의 저장소에 대한 커밋에서 우리가 많은 인라인 주석을 남겼습니다 .

앞으로 가장 의미 있는 전략은 두 가지입니다.

• 먼저 몇 가지 테스트를 더 작성해야 합니다.
• 파서와 시스템의 다른 "프론트엔드" 부분에 알려진 단점이 있습니다. 이를 열거하고 수정해야 합니다. 테스트에서 더 많은 것을 찾을 수 있을 것입니다.
• 이 시점에서 우리는 특성 시스템을 적절하게 해킹할 준비가 되었습니다.
  
  
  
  • 기초의 일부는 이미 마련되었으므로 이것은 대부분 "리팩토링" 작업이 되기를 바랍니다.
  
  
  • 하지만 자세히 적어야 합니다. 제가 알고 있는 계획에 대한 서면 설명이 없고 지금 당장 할 시간이 없습니다.
  
  

몇 가지 지침 re: 테스트를 작성하는 것으로 시작하겠습니다. 테스트가 더 즉각적으로 실행 가능하기 때문입니다. 그리고 이번 주 후반에 나머지 디자인이 작동하는 방식과 코드를 있는 위치에서 가져오는 방법을 작성하기 위해 일정을 잡습니다. 이제 필요한 곳으로.

훌륭 하군요 !! @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 오류 수정

prohibit_type_params 에서 오류 E0110이 보고되었습니다.

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

첫 번째 단계는 호출된 위치를 파악하는 것입니다. 내가 선호하는 방법은 로컬 빌드를 얻고 RUST_BACKTRACE=1 -Ztreat-err-as-bug 를 사용하는 것입니다. 그러나 Rustc가 아직 구축 중이기 때문에 그 결과를 보여드릴 수 없습니다. :P 그래서 대신 rg prohibit_type_params 을 빠르게 수행했습니다. 제가 본 수상한 사례 하나를 빠르게 지적하겠습니다.

하나의 호출은 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 는 두 개의 멋진 PR을 받았습니다.

  • 일반 관련 유형 구문 분석 및 이름 확인 (2017-12-02 병합)
  • 일반 관련 유형에 대한 평생 해결 (2017-12-15 병합)

• 그런 다음 한동안 많은 일이 일어나지 않았습니다. 그런 다음 Niko 는 이 의견(2018-03-12)에서 여전히 발생해야 하는 일을 요약했습니다. 기본적으로 (a) 테스트 작성, (b) 파서/프론트 엔드의 버그 수정/개선 및 (c) 특성 시스템의 구현. 점 (a)는 이 의견 (2018-03-13)에서 추가로 설명되었습니다.

• @gavento 는 RFC1598(GAT)에 대한 확장 테스트를 시작했습니다( 2018-05-11 병합).

  • 테스트에 대한 Niko의 의견 이 이 PR의 변경 사항을 이미 반영하고 있는지 확실하지 않습니다. 최신 편집은 @gavento가 PR을 연 같은 날인 2018-03-27 입니다. ( @gavento 상태를 알려주실 수 있나요?)

그 이후로 UI 테스트가 추가되지 않았습니다 . 그리고 GAT와 직접적으로 관련된 다른 PR을 찾을 수 없습니다.

그러나 위의 (c)(특성 시스템)은 "비밀로" 작업 중입니다. 내가 이해하는 한, 계획은 곧 새로운 분필 기반 특성 솔버로 마이그레이션하고 GAT가 이전 시스템에서 작동 하지 않도록 하는 것입니다. 새로운 특성 솔버의 통합은 "Chalkification" 추적 문제 로 추적됩니다. 분필 및 백악화와 관련된 꽤 많은 PR이 있었습니다. 특히 "GAT 구현 완료" (2018-05-24 병합)라는 초크 PR이 있습니다. 따라서 GAT의 핵심 시스템은 이미 제자리에 있는 것 같습니다.

즉, 분필로 표시된 "GAT"는 프로토타입 구현이며 rustc에서 사용하는 것은 단지 use chalk; 가 아닙니다. @scalexm 이 나에게 말했듯이: "할 일이 꽤 많은 것 같습니다."

더 많은 정보를 얻고 도움을 받으려면 #wg-traits Discord 채널과 WG 추적 문제 특성 을 살펴보는 것이 도움이 될 것입니다.

그래서 @nikomatsakis 는 rust-lang discord 서버에 #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 nightly를 사용하여 다음을 시도했습니다.

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 나는 그것이 결국 가능해야 한다고 생각하지만 기능 구현은 아직 완료되지 않았습니다(사실, 컴파일러는 사용하려고 할 때 충돌할 수 있다고 경고합니다!). 타임라인이 뭔지 모르겠네요.

이 기능에 대한 작업을 재개할 수 있을 만큼 통합이 충분히 진행되었는지 확인하기 위해 Chalk 직원에게 확인해 볼 가치가 있습니까?

이것은 이제 차단되었습니다.

• #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{}

내 특성의 모든 구현자를 "newtype"(f64를 래핑하는 단일 요소 튜플 구조체)로 제한할 수 있기를 바랍니다.

제안된 구현이 여기에서 고려된다면 가능할까요?

다음은 약간 이상하게 보이지만 내가 할 수 있기를 원하는 것을 보여주기를 바랍니다.

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

@ChechyLevas 내가 아는 한 이것은 GADT의 범위에 속하지 않습니다.

그러나 당신이하고 싶은 것은 GADT가 필요하지 않습니다. 내가 수집 할 수있는 것에서, 당신이 그것이 새로운 유형이라는 보장을 기꺼이 포기하고 대신 내부 값을 각각 감싸고 검색하는 기능을 가져야한다면 . 편리하지는 않지만 충분히 잘 작동해야 합니다.

따라서 다음을 수행할 수 있습니다.

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

(이것은 매크로를 통해 수행할 양방향으로 From 도 구현해야 합니다.)

이 상황에 대해 약간의 느낌을 받고 싶습니다. 나는 비동기 특성과 수명을 약간 가지고 놀았습니다.
내가 하고 싶었던 한 가지는 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 위의 스니펫이 작동할 수 있습니다. ;-) )

유형 매개변수가 아닌 수명 매개변수만 사용하기 때문에 수명 매개변수가 vtable과 유형 크기에 어떻게든 영향을 줄 수 없다면 기술적으로 가능해야 한다고 생각합니다.

@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를 적용하려고 시도했는데 오류가 하나만 발생합니다(현재로서는). 하지만 해당 오류는 앞서 언급한 문제에 대한 수정 사항에 따라 달라지므로 간단히 고칠 수 없습니다.

수명 제한은 연결된 유형에 추가할 수 있습니다(특성 버전에서 Self: 'ast 사용). 이 테스트는 다음과 같이 보여야 합니다.
https://github.com/rust-lang/rust/blob/db4826dd6ca48663a0b4c5ab0681258999017c7d/src/test/ui/generic-associated-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

코드가 한 단계를 통과한 것처럼 보입니다(이전에는 유사한 오류로 오류가 발생했지만 그 사이에 E0107 로만 구성된 또 다른 범주의 오류가 나타남) 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 의 impl에 대한 직접 링크가 있습니다.

컴파일러는 이에 대해 무엇이라고 말합니까?:

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 구현이 하나 있습니다.

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 용도에는 수명 매개변수가 하나만 필요합니다. 축소된 평생 전용 버전의 GAT가 제공하기 더 간단할까요?

https://github.com/rust-lang/rust/issues/44265#issuecomment -568247656은 (다소 간결한) 업데이트입니다.

67510은 구현해야 하는 마지막 주요 ICE/누락 기능입니다.

이 RFC가 Monad 및 Functor 를 직접 가능하게 합니까? 아니면 HKT에서 해야 할 일이 더 있습니까?

이 RFC가 Monad와 Functor를 직접 가능하게 만들까요? 아니면 HKT에서 해야 할 일이 더 있습니까?

@ibraheemdev RFC 상태

이것은 사람들이 더 높은 종류의 유형에 대해 이야기할 때 원하는 모든 기능을 추가하지 않습니다. 예를 들어, Monad와 같은 특성을 활성화하지 않습니다. 어떤 사람들은 이러한 모든 기능을 한 번에 함께 구현하는 것을 선호할 수 있습니다. 그러나 이 기능은 다른 종류의 고급 다형성과 호환되며 어떤 식으로든 구현을 방해하지 않습니다. 사실, 부분 적용과 같이 다른 종류의 고급에도 영향을 미칠 일부 구현 세부 사항을 해결함으로써 길을 닦습니다.

@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에서 고급 유형을 에뮬레이트하는 방법을 참조하세요. 지금은 안정적인 상태에서도 작동합니다.