यहां एक प्रकार की कार्यान्वयन योजना है जिसे मैं अद्यतन रखने का प्रयास करूंगा।

• [] चरण एक: एएसटी और सुंदर-प्रिंटिंग में समर्थन जोड़ें
  
  
  
  • संभवत: पहला कदम नए रूपों को पार्स करना शुरू करना और एएसटी में उनके लिए समर्थन जोड़ना है।
  
  
  • अधिक विस्तृत विचारों के लिए यह टिप्पणी यहाँ देखें।
  
  
  • हमें कुछ केवल-पार्सिंग परीक्षण लिखने में सक्षम होना चाहिए और सुंदर-प्रिंटर का परीक्षण भी करना चाहिए
  
  
  • जब हम एचआईआर कम करते हैं, तो हम गलती कर सकते हैं कि क्या कोई GAT मौजूद है
  
  
  • हम तब फीचर गेट भी कर सकते हैं
  
  
• [ ] और भी आने को है

मैं एएसटी के बारे में अधिक विस्तार से लिखकर शुरू करता हूं। आइए पहले चर्चा करें कि यह आज कैसे काम करता है:

एक विशेषता परिभाषा में एक type Foo: Bar [= Baz]; आइटम इस एएसटी संस्करण द्वारा परिभाषित किया गया है। इसमें सीमाएं ( Bar ) और (वैकल्पिक) डिफ़ॉल्ट मान Baz शामिल हैं। नाम TraitItem संरचना में परिभाषित किया गया है ।

एक विशेषता impl में एक type Foo = Bar; आइटम इस AST संस्करण द्वारा परिभाषित किया गया है - जिसमें केवल Bar प्रकार शामिल है, क्योंकि Foo आदि को ImplItem में परिभाषित किया गया है ।

तरीके एक दिलचस्प मामला है क्योंकि उन्हें पहले से ही सामान्य बनाया जा सकता है। उन सामान्य मापदंडों को MethodSig संरचना के Generics क्षेत्र में घोषित किया गया है । यह Generics संरचना का एक उदाहरण है।

मेरा मानना ​​है कि करने के लिए सबसे अच्छी बात यह होगी कि Generics को विधियों से TraitItem (और ImplItem ) में "उठाना" ताकि यह सभी रूपों पर समान रूप से लागू हो विशेषता और निहित आइटम। अभी के लिए, हम सामान्य स्थिरांक का समर्थन नहीं करेंगे, मुझे लगता है, लेकिन ईमानदारी से वे शायद किसी भी मामले में हम जो काम कर रहे हैं उससे बाहर हो जाते हैं, इसलिए वे एक छोटा सा विस्तार होगा। मुझे लगता है कि अगर हम अभी उनके लिए योजना बनाते हैं तो काम बेहतर होगा।

शायद एक अच्छा पहला पीआर सिर्फ उस बदलाव को करना होगा, अन्य सभी मौजूदा कार्यक्षमताओं को समान रखते हुए। यानी, हम Generics को TraitItem (और ImplItem ) में और MethodSig में से अधिक करेंगे। हम गैर-विधियों के लिए एक खाली Generics की आपूर्ति करेंगे। हम मौजूदा कोड के माध्यम से काम करेंगे, इसे काम करने के लिए आवश्यकतानुसार जेनरिक को प्लम्बिंग करेंगे।

@nikomatsakis कूल! बहुत - बहुत धन्यवाद! मैंने कल रात इसके साथ प्रयोग करना शुरू किया और मुझे यह कहते हुए गर्व हो रहा है कि मुझे वही स्थान मिले, जिनकी ओर आपने एएसटी के बारे में अपनी टिप्पणी में बताया था। : मुस्कान: (यह देखते हुए कि यह मेरा पहली बार जंग में था, मैं इसे एक उपलब्धि के रूप में मानता हूं!)

मैंने जेनेरिक को 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 . पर निकोमात्सकिस द्वारा उत्तर

उन्हें टाइप करने के नुकसान के बारे में
मुझे लगता है कि यह भी काम कर सकता है
जिस कारण से मैं ऐसा करने के लिए अनिच्छुक था
यह है कि हम वास्तव में वही काम करना चाहते हैं (सिद्धांत रूप में, कम से कम) विधियों और प्रकारों के लिए
और - जैसा कि मैंने कहा - सिद्धांत रूप में मुझे कोई कारण नहीं दिखता है कि हम स्थिरांक के लिए समान चीजें नहीं कर सकते हैं
मुझे लगता है कि अगर आप जेनरिक को टाइप वैरिएंट में ले जाते हैं
यह शायद ठीक काम करेगा, लेकिन अगर आप देखें, तो अभी हमें अक्सर "एक चीज प्रकार/स्थलों के लिए, विधियों के लिए एक चीज" ठीक से करना पड़ता है क्योंकि वे अलग हैं
इसलिए मुझे संदेह है कि कोड और अधिक समान हो जाएगा
मुझे सच में यकीन नहीं है कि यह कैसे ईमानदार होगा =) - यह एक दर्द हो सकता है
लेकिन कई बार चीजों का अधिक सामान्य होना इतना बुरा नहीं है, क्योंकि आप span_bug डाल सकते हैं! अभी के लिए असंभव मामलों में कॉल करें (और बाद में हम चारों ओर आते हैं और उन्हें ठीक करते हैं)

ठीक है! अगला कदम पार्सर का विस्तार करना है। यहां कुछ सलाह हैं। आइए विशेषता वस्तुओं से शुरू करें।

यह रूटीन विशेषता आइटम को पार्स करता है । हम उस मामले का विस्तार करना चाहते हैं जो संबंधित प्रकारों को type Foo<....> = ...; (शायद जहां-क्लॉज भी) जैसी चीजों को पार्स करने के लिए संभालता है। ( <...> "जेनेरिक" है जिसे हमने अभी एएसटी में जोड़ा है।)

वर्तमान में यह parse_ty_param का उपयोग कर रहा है, जो मूल रूप से T: Foo आदि जैसे कुछ को पार्स करता है। हमें ऐसा करना बंद करना होगा, क्योंकि संबंधित प्रकार की घोषणाओं के लिए व्याकरण अब टाइप पैरामीटर के लिए मेल नहीं खाता है। तो हम शायद parse_trait_item_assoc_ty जैसा कुछ जोड़ना चाहेंगे। यह parse_ty_param() के एक प्रकार के क्लोन के रूप में शुरू हो सकता है, लेकिन फिर हम इसे यहीं संशोधित करने के लिए parse_generics() को लागू करना चाहेंगे। यदि कोई मौजूद है तो वह दिनचर्या एक जेनेरिक घोषणा ( <...> ) को पार्स करेगी, अन्यथा यह सिर्फ एक खाली जेनरिक लौटाती है। फिर हम पार्स करने के लिए एक कॉल जोड़ना चाहते हैं जहां क्लॉज यहीं हैं - आप उस कॉल पर मॉडल कर सकते हैं जो पार्सिंग विधियों के दौरान होती है , ध्यान दें कि परिणाम generics में संग्रहीत है जिसे हमने पहले पार्स किया था।

एक बार ऐसा करने के बाद, हमें कुछ पार्सिंग परीक्षण जोड़ने में सक्षम होना चाहिए। मैं ऐसा src/test/run-pass/rfc1598-generic-associated-types/ जैसी निर्देशिका बनाकर और उन फ़ाइलों को जोड़कर करूंगा जिनकी आप वहां सफलतापूर्वक पार्स करने की उम्मीद करते हैं। अभी वे ठीक से काम नहीं करेंगे, लेकिन इससे कोई फर्क नहीं पड़ता। बस एक खाली मुख्य कार्य जोड़ें। फिर हम ऐसे उदाहरण भी जोड़ सकते हैं जिन्हें src/test/ui/rfc1598-generic-associated-types/ में पार्स नहीं करना चाहिए ( यूआई परीक्षण जोड़ने के निर्देशों के लिए COMPILER_TESTS.md देखें)।

कुछ और - हमें इस बिंदु पर इस काम को गेट करने की ज़रूरत है, ताकि लोग इस सामान को स्थिर निर्माण में उपयोग करने से बच सकें। फोर्ज पर यहां फीचर-गेट जोड़ने के लिए कुछ निर्देश हैं (अंतिम खंड देखें)। हमें visit_trait_item और visit_impl_item में विज़िटर को feature_gate.rs में जोड़ना चाहिए; यदि वह आइटम एक विधि नहीं है, लेकिन इसमें एक गैर-रिक्त जेनरिक है, तो हम 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 के लिए, हमें एक खाली प्रकार पैरामीटर रिब ( NoTypeParameters ) जोड़ने के लिए हार्डकोड किया गया है:

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

अब जब जेनरिक प्रत्येक विशेषता/निहित वस्तु पर मौजूद हैं, तो मुझे लगता है कि हम शायद type के लिए हैंडलिंग को हटाना चाहते हैं और विधि प्रबंधन को निकालना चाहते हैं ताकि यह उच्च स्तर पर हो। वस्तुओं के लिए (उदाहरण के लिए, const ) जहां कोई जेनरिक नहीं हैं, तो नई पेश की गई पसली खाली होनी चाहिए और इसलिए हानिरहित (मुझे आशा है)।

रुचि के अन्य बिंदु:

• जहां impl आइटम विधियाँ सेटअप हैं
• जहां type impls में सेटअप हैं

तुम्हें नया तरीका मिल गया है।

@petrochenkov - सही के बारे में ध्वनि?

@nikomatsakis

सही के बारे में ध्वनि?

सब कुछ सही दिखता है।

अगला कदम। आजीवन संकल्प।

बेहतर या बदतर के लिए, यह वर्तमान में अन्य नाम समाधान से पूरी तरह से अलग कोड में किया जाता है। ऐसा इसलिए है क्योंकि यह एचआईआर के निर्माण के बाद होता है। लगभग निश्चित रूप से यह बदलेगा लेकिन यह अभी तक नहीं बदला है।

मूल विचार सामान्य नाम संकल्प के समान हैं, हालांकि, सिवाय इसके कि हम चीजों को "पसलियां" नहीं कहते हैं, बल्कि "स्कोप" कहते हैं। =)

"देर से बंधे" जीवन काल की इस अवधारणा के कारण कुछ हल्की जटिलताएँ हैं। हालांकि यह वास्तव में प्रासंगिक नहीं है - एक सामान्य संबद्ध प्रकार के लिए सभी जीवनकाल "प्रारंभिक-बाध्य" होंगे, जो कि साधारण मामला है। एक "देर से बाध्य" जीवनकाल एक विधि या कार्य पर घोषित जीवनकाल है जिसका मूल्य विधि लागू होने तक आपूर्ति नहीं किया जाता है। मैं यहां विवरण में नहीं जाऊंगा क्योंकि यह उतना प्रासंगिक नहीं है - मुख्य बात यह है कि हम विधियों के लिए ठीक उसी मॉडल का पालन नहीं करना चाहते हैं जैसा कि हम अन्य प्रकार के सामान्य वस्तुओं के लिए करते हैं, अन्य नाम संकल्प के विपरीत मामले

कोड का एक उदाहरण बिट यहां दिया गया है। यह वह कोड है जो 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 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

दोनों को, संबद्ध प्रकारों के लिए, संबद्ध जेनरिक को संसाधित करने की आवश्यकता होगी। (अन्य मामलों में, उन्हें संभवतः जोर देना चाहिए कि जेनरिक खाली हैं।)

तो मैं आज पहले इस पर कूद पड़ा। मैं यह सुनिश्चित करना चाहता हूं कि मैं सही रास्ते पर हूं:

• बस इतना करने की जरूरत थी कि जीवन भर को मानचित्र से परिचित कराया जाए और फिर विशेषता/निहित वस्तु को चलाया जाए? जाँच काम कर रही प्रतीत होती है, हालाँकि यह बताना कठिन है (बाद में देखें)...
• मैंने type parameters are not allowed on this type त्रुटियों को ठीक करने के लिए qpath_to_ty और associated_path_def_to_ty में librustc_typeck/astconv.rs के लिए टाइप पैरामीटर निषेध छोड़ दिया। मुझे लगता है कि इसे कुछ चेक के साथ बदलने की जरूरत है। भी...
• मुझे अब टाइपेक से क्रैश हो रहा है। (राइटबैक, विशेष रूप से)

टाइपेक विफलताओं को src/test/compile-fail/struct-path-associated-type.rs ट्रिगर किया जाता है क्योंकि यह उन मानों को जेनरिक प्रदान करता है जिनका कोई संबद्ध प्रकार नहीं है।

अगर मैं चीजों को सही तरीके से पढ़ रहा हूं, तो मुझे कम से कम एक चेक जोड़ना होगा कि संबंधित जेनेरिक गिनती मेल खाती है (यह पता लगाने की कोशिश कर रही है कि यह कहां करना है ...), और संभवतः नोड्स आदि के लिए प्रकार जोड़ने के लिए अन्य चेक भी करें।

उस पर काम करने जा रहे हैं, लेकिन क्या मैं सही दिशा में जा रहा हूं, इस पर संकेत की सराहना की जाती है।

हाय @ ब्रैंडनसन! मैं रस्ट कंपाइलर पर हैकिंग से किसी को भी हतोत्साहित करने के लिए घृणा करता हूं, लेकिन मुझे लगता है कि @sunjay पहले से ही एक ही सामान पर सक्रिय रूप से हैकिंग कर रहा था और शुरुआत से ही इस बदलाव का पीछा कर रहा है, इसलिए शायद यह उनके लिए खत्म करने के लिए समझ में आता है यह परिवर्तन भी (मुझे लगता है कि वे पहले ही शुरू हो चुके हैं)। मुझे यकीन नहीं है कि इस प्रयास को समानांतर करने का कोई स्पष्ट तरीका है (निश्चित रूप से यह संभव है, लेकिन हमें हाथ से थोड़ा पहले कदम उठाना होगा)।

हालांकि, यदि आप निपटने के लिए कुछ खोजने में रुचि रखते हैं, तो क्या मैं इस मील के पत्थर पर कुछ बग से निपटने की सिफारिश कर सकता हूं? ऐसा लगता है कि https://github.com/rust-lang/rust/issues/46472 के लिए बात नहीं की जा रही है, मैं जल्द ही वहां कुछ टिप्पणियां छोड़ने की कोशिश कर सकता हूं।

निश्चित रूप से मेरा मतलब किसी के पैर की उंगलियों पर कदम रखने का नहीं है, लेकिन मुझे ऐसा कुछ भी दिखाई नहीं दे रहा था जो वास्तव में आगे की प्रगति का संकेत दे रहा था (हालांकि माना जाता है कि अगले चरणों के बारे में टिप्पणी हाल ही में है)। वास्तव में, मैंने इसे हल करने का प्रयास करना शुरू कर दिया क्योंकि मैं पिछले कुछ दिनों में कई बार जीएटी चाहता था, इसलिए जब मुझे भविष्य में कुछ एनएलएल सामान के माध्यम से काम करने में कोई दिक्कत नहीं होगी, तो यह मेरी चीजों की सूची में हल करने का तरीका है इस समय।

@ संजय , यदि आप अभी भी सक्रिय रूप से काम कर रहे हैं/इस पर काम करने की योजना बना रहे हैं, तो कृपया मुझे बताएं - मुझे इस पर अपना काम डुप्लिकेट करने का कोई मतलब नहीं है।

नमस्ते @brandonson , आपकी उत्सुकता और मदद करने की इच्छा के लिए धन्यवाद। :) मैं वास्तव में इस पर सक्रिय रूप से काम कर रहा हूं। मैं इसे ठीक करने के लिए निको के साथ मिलकर काम करते हुए कार्यान्वयन के प्रत्येक भाग को चरण दर चरण देख रहा हूं।

मैं इसे जल्द से जल्द बाहर निकालने के लिए हर संभव कोशिश करूंगा। मैं वास्तव में यह सुविधा भी चाहता हूँ!

प्रगति कैसी चल रही है? =) रात में इसके साथ प्रयोग करने के लिए इंतजार नहीं कर सकता <3

मुझे आश्चर्य है कि GAT और कॉन्स्ट जेनरिक का क्रॉस सेक्शन कैसे काम करेगा और क्या यह प्रस्तावों का हिस्सा था जब एक साथ रखा गया था?

मेरा क्या मतलब है इसका एक उदाहरण:

trait Foo {
    type Bar<const N>;
}

हाय @ संजय मुझे लगता है कि यह काफी महत्वपूर्ण विशेषता है, 2018 रोडमैप टिप्पणियों में इसका भारी उल्लेख किया गया था। यह कैसे आगे बढ़ रहा है? आपके काम के लिए धन्यवाद!

यह इस समय मेरी सबसे वांछित विशेषता है। मुझे उम्मीद है कि यह एक प्राथमिकता बन जाएगी और जल्द ही रात में अपना रास्ता खोज लेगी!

इसलिए हाल ही में मैं @sunjay से मिला, जो अभी स्कूल और अन्य चीजों में व्यस्त है, कोशिश करने और अगले चरणों को यहाँ रखने के लिए। वे और मैं किसी बिंदु पर मिले थे और समग्र कार्यान्वयन रणनीति पर चर्चा की थी, जिसका समापन उनके रेपो पर एक प्रतिबद्धता में हुआ जहां हमने इनलाइन टिप्पणियों का एक गुच्छा छोड़ा ।

मुझे लगता है कि आगे बढ़ने वाली रणनीति दो गुना है:

• सबसे पहले, हमें कुछ और परीक्षण लिखने होंगे।
• हमारे पार्सर और सिस्टम के कुछ अन्य "फ्रंट-एंड" बिट्स में कुछ ज्ञात कमियां हैं, हमें उन्हें गिनने और उन्हें ठीक करने की आवश्यकता है। हम शायद परीक्षणों में और अधिक पाएंगे।
• उस समय, हम विशेषता प्रणाली को उचित रूप से हैक करना शुरू करने के लिए तैयार हैं:
  
  
  
  • कुछ नींव पहले ही रखी जा चुकी है, इसलिए उम्मीद है कि यह काफी हद तक "रिफैक्टरिंग" कार्य है
  
  
  • लेकिन मुझे विस्तार से लिखने की जरूरत है, उस योजना का कोई लिखित विवरण नहीं है जिसे मैं जानता हूं और मेरे पास इस मिनट के लिए समय नहीं है।
  
  

मैं कुछ निर्देशों को फिर से लिखने की कोशिश करके शुरू करूंगा: परीक्षण, क्योंकि वे अधिक तुरंत कार्रवाई योग्य हैं, और इस सप्ताह के अंत में यह लिखने के लिए शेड्यूल करें कि बाकी डिज़ाइन कैसे काम करेगा और कोड कैसे प्राप्त करें जहां से यह है अब जहां इसकी जरूरत है।

यह तो बहुत ही अच्छी बात है !! इस और अन्य सभी प्रयासों में @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 उपयोग करना है। लेकिन मैं आपको वे परिणाम नहीं दिखा सकता क्योंकि जंग अभी भी बन रही है। :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

जैसा कि टिप्पणी इंगित करती है, इसे Pointer<T> घटक को Self::Pointer<T> जैसे पथ में हल करने के लिए आमंत्रित किया जाता है (ध्यान दें कि टाइप पैरामीटर को पथ खंड का हिस्सा माना जाता है, साथ ही वे जिस नाम से जुड़े होते हैं ) GATs तक, टाइप पैरामीटर वहां कानूनी नहीं थे (उदाहरण के लिए, 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- लक्षणों की गड़बड़ी पर बात कर रहे थे, लेकिन मुझे नहीं पता कि कोई प्रगति हुई है या नहीं। हो सकता है कि वे इसमें शामिल हों। मुझे लगता है कि एक पीआर का स्वागत किया जाएगा। =)

क्षमा करें यदि मैं मूर्ख हूं, लेकिन क्या इस तरह की बात 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>;
}

इसकी स्थिति क्या है? मुझे पता है कि चाक को हाल ही में समर्थन मिला है। क्या इसका इरादा जल्द ही जंग में उतरने का है?

@ मार्क-आईएम मैंने इसे पिछले हफ्ते एक शॉट दिया था। मेरी समझ से, सिंटैक्स पार्सर है (हालांकि लापता परीक्षण)। लेकिन "कार्यान्वयन" अभी तक नहीं लिखा गया है। (अधिक जानकारी के लिए https://github.com/rust-lang/rust/issues/44265#issuecomment-330915766 देखें)

@quadrupleslap AIUI, यह बाद में संभव होगा, लेकिन सबसे पहले, GAT केवल आजीवन मापदंडों का समर्थन करेगा।

@ बॉस्कोप आरएफसी निर्दिष्ट करता है कि टाइप पैरामीटर भी समर्थित होंगे।

क्या किसी को रस्टसी में सिंटैक्स के कार्यान्वयन की सही स्थिति पता है? यह ज्यादातर वहां लगता है, लेकिन उच्च रैंक वाली सीमाएं आईसीई उत्पन्न करती हैं:
http://play.rust-lang.org/?gist=a48959858ed5dd432c2396feae5c3cc1&version=nightly&mode=debug

चाकीकरण कार्य पर आगे बढ़ने के लिए मुझे कम से कम पूरे वाक्यविन्यास को लागू करने की आवश्यकता होगी। अगर कोई अभी भी वाक्यविन्यास पर काम कर रहा है, तो कृपया मुझे बताएं, अन्यथा मैं जा सकता हूं और इसे स्वयं ठीक कर सकता हूं :)

मेरे लिए ऐसा लगता है कि संचार GAT के कार्यान्वयन को धीमा करने वाली प्रमुख समस्या है। ऐसा लगता है कि कम से कम कुछ लोग इस पर काम करने में रुचि रखते हैं, लेकिन कोई भी वास्तव में सटीक कार्यान्वयन स्थिति नहीं जानता है और कौन पहले से ही इस पर काम कर रहा है। GAT को लागू करने के बारे में बात करने के लिए आप एक Discord (या IRC?) चैनल के बारे में क्या सोचते हैं? मुझे लगता है कि यह निश्चित रूप से मदद करेगा।

इसके अलावा, मैं निश्चित रूप से इस पर काम करने के लिए निम्नलिखित हफ्तों में कुछ कार्य दिवसों का योगदान कर सकता हूं (लेकिन मुझे अभी तक कंपाइलर के इस हिस्से के बारे में कुछ भी नहीं पता है)।

इसलिए मैंने डिस्कॉर्ड पर एक समर्पित चैनल मांगा। लेकिन चैनल मिलने के बजाय मैंने कुछ चीजें सीखीं। मैंने GAT से संबंधित हर चीज की खोज की। इसलिए मैं इस सुविधा के संबंध में सभी जानकारी को संक्षेप में प्रस्तुत करने का प्रयास करूंगा; शायद यह कुछ लोगों के लिए उपयोगी है। लेकिन मैं कुछ नहीं जानता, इसलिए इसे नमक के दाने के साथ ले लो! इसके अलावा: कृपया मुझे बताएं कि क्या कुछ जानकारी गलत है ताकि मैं इसे ठीक कर सकूं।

GAT के संबंध में कार्यान्वयन प्रयासों का सारांश

• @sunjay ने दो शानदार PR को उतारा:

  • सामान्य संबद्ध प्रकार पार्सिंग और नाम समाधान (मर्ज 2017-12-02)
  • जेनेरिक एसोसिएटेड प्रकारों के लिए आजीवन संकल्प (2017-12-15 का विलय)

• फिर, कुछ समय के लिए, बहुत कुछ नहीं हुआ। इसके बाद निको ने संक्षेप में बताया कि इस टिप्पणी में अभी क्या होने की जरूरत है (2018-03-12)। मूल रूप से (ए) परीक्षण लिखें, (बी) पार्सर/फ्रंट-एंड में बग को ठीक करें/सुधारें और (सी) विशेषता प्रणाली में कार्यान्वयन। इस टिप्पणी (2018-03-13) में बिंदु (ए) को और समझाया गया था।

• @gavento RFC1598 (GAT) के लिए परीक्षण बढ़ाएँ ( 2018-05-11 में विलय)

  • मुझे यकीन नहीं है कि परीक्षणों के बारे में निको की टिप्पणी पहले से ही इस पीआर में किए गए परिवर्तनों को दर्शाती है। नवीनतम संपादन 2018-03-27 से है, उसी दिन @gavento ने अपना पीआर खोला। ( @gavento क्या आप हमें स्थिति के बारे में बता सकते हैं?)

तब से कोई UI परीक्षण नहीं जोड़ा गया । और मुझे सीधे GAT से संबंधित कोई अन्य पीआर नहीं मिल रहा है।

हालांकि , ऊपर से बिंदु (सी) (विशेषता प्रणाली) पर "गुप्त रूप से" काम किया जा रहा है। जहां तक ​​मैं इसे समझता हूं, योजना जल्द ही नए चाक-आधारित विशेषता सॉल्वर में माइग्रेट करने की है न कि पुराने सिस्टम पर GAT को काम करने के लिए। नए विशेषता सॉल्वर का एकीकरण "चॉकीफिकेशन" ट्रैकिंग समस्या द्वारा ट्रैक किया जा रहा है। चाक और चाकीकरण से संबंधित काफी कुछ पीआर हैं। विशेष रूप से, एक चाक पीआर है जिसे "जीएटी लागू करना समाप्त करें" (मर्ज 2018-05-24) कहा जाता है। तो ऐसा लगता है कि GAT के लिए कोर सिस्टम पहले से ही मौजूद है।

उस ने कहा, चाक में "GATs" एक प्रोटोटाइप कार्यान्वयन है और इसे rustc में उपयोग करना केवल use chalk; नहीं है। जैसा कि @scalexm ने मुझे बताया: "ऐसा लगता है कि बहुत कुछ [करने के लिए]" है।

अधिक जानकारी के लिए और मदद करने के लिए, #wg-traits डिस्कॉर्ड चैनल और WG ट्रैकिंग समस्या के लक्षणों पर एक नज़र डालना संभवतः उपयोगी है।

तो @nikomatsakis ने रस्ट-लैंग डिसॉर्डर सर्वर पर #wg-traits-gat चैनल बनाया ( यहां शामिल हों )। यह बहुत अच्छा होगा यदि हम हर उस व्यक्ति को प्राप्त कर सकें जो वहां मदद करना चाहता है। साथ ही कुछ लोग जो इस सुविधा की स्थिति के बारे में जानते हैं (विशेष रूप से, अभी भी क्या करने की आवश्यकता है और हम कहाँ मदद कर सकते हैं)। इससे संचार आसान और तेज़ होना चाहिए, खासकर मेरे जैसे लोगों के लिए जो अभी तक गहराई से शामिल नहीं हैं/WG के लक्षणों का हिस्सा हैं :)

क्या इस पर हाल ही में कोई अपडेट आया है? क्या हम संकलक में चाक एकीकरण की प्रतीक्षा कर रहे हैं? (शायद इसके लिए एक अलग मुद्दा है।)

शायद इसके लिए एक अलग मुद्दा है।

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!()
    }
}

(यह वास्तव में संकलित करता है)

शायद यह एक समर्थन प्रश्न है, लेकिन मुझे लगता है कि यह इस प्रस्ताव को समझने के लिए इस पृष्ठ पर आने वालों के लिए उपयोगी हो सकता है क्योंकि यह आरएफसी या यहां टिप्पणियों से मुझे पूरी तरह से स्पष्ट नहीं था:

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 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

क्या हम समस्या विवरण को वर्तमान अवरोधकों के साथ अद्यतन कर सकते हैं?

@DuchGhost द्वारा उठाए गए अधिक अवरोधन मुद्दों को जोड़ा गया

यह उच्च प्रकार के प्रकारों के अनुकरण में एक प्रमुख कदम होगा।

मैं कुछ इस तरह की कल्पना कर रहा हूँ:

// 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 जहाँ तक मुझे पता है यह GADTs के दायरे में नहीं है।

लेकिन आप जो करना चाहते हैं, उसे शुरू करने के लिए जीएडीटी की आवश्यकता नहीं है, जो मैं इकट्ठा कर सकता हूं, अगर आप इस गारंटी को छोड़ने के इच्छुक हैं कि यह एक नया प्रकार है और इसके बजाय क्रमशः आंतरिक मूल्य को लपेटने और पुनर्प्राप्त करने वाले कार्यों को करना है . यह उतना सुविधाजनक नहीं है, लेकिन शायद पर्याप्त रूप से काम करना चाहिए।

तो आप निम्न कार्य कर सकते हैं:

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

(इसके लिए आपको दोनों दिशाओं में From को भी लागू करना होगा, जो मैं एक मैक्रो के माध्यम से करूंगा)

मैं इस की वर्तमान स्थिति के बारे में थोड़ा महसूस करना चाहता हूं। मैं async लक्षणों और जीवनकाल के साथ थोड़ा सा खेल रहा हूं।
एक चीज जो मैं करना चाहता था, वह थी trait ReadAt<'r> को एक संबद्ध ReadAt: Future प्रकार के साथ बनाना। जो कई मामलों के लिए काम करता है, सिवाय इसके कि जब मैं विशेषता वस्तुओं का उपयोग करना चाहता हूं।

अधिकतर क्योंकि निम्नलिखित करने से मुझे 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>>`
    ...
}

तो मैंने सोचा, शायद इसे जीएटी के साथ हल किया जा सकता है, लेकिन मैं इसी तरह के मुद्दों में भाग गया जहां मुझे फिर से कुछ वाक्यविन्यास जादू की आवश्यकता होगी, क्योंकि विशेषता वस्तुओं को संबंधित प्रकारों की आवश्यकता होती है:

पसंद:

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 बहुत ठोस है:

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 आपका कोड नवीनतम रात (1.46) के साथ संकलित और चलता है। मैंने कस्टम प्रकार आदि के साथ कुछ परीक्षण किए .. लेकिन मुझे और अधिक जांचने के लिए एफपी ज्ञान की कमी है।

आज, मैंने किसी ऐसी चीज़ के लिए GATs का उपयोग करने की कोशिश की, जहाँ मुझे लगा कि शायद जीवन भर सामान्य नहीं होगा (काम करने वाला कोड इस प्रकार है; पूर्ण कोड फ़ाइल ):

/// 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 ) के साथ विफल रहता है। मुझे यकीन नहीं है कि इसे कैसे ठीक किया जाए या अगर मुझे कुछ गलत धारणा है। कंपाइलर चाहता है कि मैं T पर impl स्तर पर एक बाउंड संलग्न करूं, लेकिन उस स्तर पर, कोई आजीवन '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 s शामिल था) एचएम।

संपादित करें : मुझे पहला कथन याद आया ( 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 फ़ंक्शन एक अलग तर्क की अपेक्षा कर सकता है, इसलिए प्रकार बेमेल है।

@ सिघोया मैंने पिछली पोस्ट में रिपॉजिटरी को लिंक किया है, यहाँ crate::view::ViewFn::map के इम्प्लांट का सीधा लिंक है

इस बारे में संकलक ने क्या कहा ?:

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

यह पार्स नहीं करता है (अभी तक)।

@matthewjasper ,

रस्ट नोमिकॉन से, निम्नलिखित पार्स:

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

क्या यह Output<'x> = &'x 0> के उपयोग के कारण है कि यह पार्स नहीं करता है?

हां, Output<'x>=... उस स्थिति में पार्स नहीं करता है।

मेरे पास एक create, grdf है जो अब rustc 1.46.0-nightly के साथ संकलित नहीं करता है। क्या हाल ही में 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 पहले से ही 'a से Iter में बंधा हुआ है ...

ठीक है मैंने कुछ where सीमा जोड़कर इसे फिर से काम किया।
विशेषता में:

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

और कार्यान्वयन में:

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

लेकिन मुझे निश्चित रूप से where सीमा के सटीक शब्दार्थ को समझना निश्चित नहीं है, विशेष रूप से कार्यान्वयन में (पहली बार मैंने इसे देखा है)। और यह भी कि यह पहले क्यों काम करता था।

संपादित करें: मैं भी अपने खराब हैक को हटाने में सक्षम हूं और संबंधित इटरेटर्स को विशेषता में ही डाल दिया है।

@DuchGhost द्वारा उठाए गए अधिक अवरोधन मुद्दों को जोड़ा गया

आप https://github.com/rust-lang/rust/issues/74684 भी जोड़ सकते हैं :)

मुझे लिखना पसंद नहीं है कृपया पहले से ही पोस्ट जल्दी करें, लेकिन यह सुविधा लगभग तीन साल पहले से ही रुकी हुई है, और मेरा मानना ​​है कि यह सबसे वांछित नई सुविधाओं में से एक है।

हम इसके साथ कहां हैं? यहां सबसे हालिया स्थिति सारांश जून 2018 से @LukasKalbertodt द्वारा दिया गया है। क्या यह "चॉकिफिकेशन" की प्रतीक्षा कर रहा है?

अनुभवहीन अवलोकन: GAT के लिए मेरे लगभग सभी वांछित उपयोगों के लिए केवल एक आजीवन पैरामीटर की आवश्यकता होती है। क्या GAT का एक कट-डाउन लाइफ़टाइम-ओनली संस्करण वितरित करना आसान होगा?

https://github.com/rust-lang/rust/issues/44265#issuecomment -568247656 एक (कुछ हद तक संक्षिप्त) अपडेट है।

67510 अंतिम प्रमुख ICE/लापता विशेषता है जिसे लागू करने की आवश्यकता है।

क्या यह RFC Monad और Functor को सीधे संभव बना देगा? या क्या एचकेटी पर और काम करने की जरूरत है?

क्या यह आरएफसी मोनाड और फनक्टर को सीधे संभव बना देगा? या क्या एचकेटी पर और काम करने की जरूरत है?

@ibraheemdev आरएफसी कहता है

यह उन सभी सुविधाओं को नहीं जोड़ता है जो लोग उच्च-प्रकार के प्रकारों के बारे में बात करते समय चाहते हैं। उदाहरण के लिए, यह मोनाड जैसे लक्षणों को सक्षम नहीं करता है। कुछ लोग इन सभी सुविधाओं को एक साथ लागू करना पसंद कर सकते हैं। हालाँकि, यह सुविधा अन्य प्रकार के उच्च-प्रकार के बहुरूपता के साथ संगत है, और उन्हें किसी भी तरह से लागू करने से नहीं रोकती है। वास्तव में, यह कुछ कार्यान्वयन विवरणों को हल करके मार्ग प्रशस्त करता है जो अन्य प्रकार की उच्च-कृपा को भी प्रभावित करेगा, जैसे कि आंशिक अनुप्रयोग।

@ibraheemdev : मेरी भावना यह है कि मोनैड और फ़ैक्टर को संभव बनाने का सबसे मुहावरेदार तरीका सामान्य संबद्ध लक्षणों को पेश करना होगा, लेकिन सामान्य संबद्ध प्रकार निश्चित रूप से एक शर्त है।

क्या Monad के लिए कोई रास्ता है जिसके लिए GAT की आवश्यकता नहीं है?

@ibraheemdev हाइपोथेटिक रूप से हां, एचकेटी को सीधे लागू करना और फिर शीर्ष पर Monad विशेषता लागू करना संभव होगा। हालाँकि, उस दिशा में कोई काम नहीं हो रहा है, और शायद कभी नहीं होगा, क्योंकि यह दृष्टिकोण वास्तव में रस्ट की समस्याओं का समाधान नहीं करता है: 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>;
}

@इब्राहीमदेव

क्या Monad के लिए कोई रास्ता है जिसके लिए GAT की आवश्यकता नहीं है?

हाँ, जंग में उच्च-प्रकार के प्रकारों का अनुकरण करने की विधि देखें। यह अब स्थिर पर भी काम करता है।