उंगलियों पर: जंग में जुड़े प्रकार और प्रकार के तर्कों से उनका अंतर क्या है

रस्ट से जुड़े प्रकार क्यों हैं, और उनके बीच अंतर क्या है और प्रकार तर्क उर्फ ​​जेनरिक, क्योंकि वे समान हैं? क्या यह केवल बाद की बात नहीं है, जैसा कि सभी सामान्य भाषाओं में होता है? उन लोगों के लिए जो बस जंग सीखना शुरू कर रहे हैं, और विशेष रूप से उन लोगों के लिए जो अन्य भाषाओं से आते हैं ("यह जेनरिक है!" - वर्षों के लिए ज्ञानी, कहेंगे), ऐसा प्रश्न नियमित रूप से उठता है। चलो ठीक है।

टीएल; डीआर पूर्व कोड को नियंत्रित करता है, बाद वाला कॉलर।

जेनरिक बनाम संबद्ध प्रकार

इसलिए, हमारे पास पहले से ही प्रकार के तर्क हैं, या सभी के पसंदीदा जेनेरिक हैं। यह कुछ इस तरह दिखता है:

trait Foo<T> { fn bar(self, x: T); } 

यहाँ T ठीक प्रकार का तर्क है। ऐसा लगता है कि यह सभी के लिए पर्याप्त होना चाहिए (जैसे कि 640 किलोबाइट मेमोरी)। लेकिन जंग में, कुछ जुड़े हुए प्रकार भी होते हैं:

 trait Foo { type Bar; //    fn bar(self, x: Self::Bar); } 

पहली नज़र में, एक ही अंडे, लेकिन एक अलग कोण से। आपको भाषा में दूसरी इकाई शुरू करने की आवश्यकता क्यों पड़ी? (जो, वैसे, भाषा के शुरुआती संस्करणों में नहीं था।)

टाइप आर्ग्युमेंट्स तर्क हैं , जिसका अर्थ है कि वे कॉल के स्थान पर विशेषता को पास कर रहे हैं, और T बजाय किस प्रकार का उपयोग किया जाएगा इस पर नियंत्रण कॉल करने वाले का है। भले ही हम कॉल स्थान पर T को स्पष्ट रूप से निर्दिष्ट नहीं करते हैं, लेकिन कंपाइलर हमारे लिए टाइप इंट्रेंस का उपयोग करेगा। यही है, स्पष्ट रूप से, वैसे भी, इस प्रकार को कॉलर पर अनुमान लगाया जाएगा और एक तर्क के रूप में पारित किया जाएगा। (बेशक, यह सब संकलन के दौरान होता है, रनटाइम में नहीं।)

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

 trait AsRef<T> { fn as_ref(&self) -> &T; } 

यहां T कॉलगर्ल द्वारा एक तर्क के रूप में पारित किया जाता है, भले ही यह अंतर्निहित रूप से होता हो (यदि कंपाइलर आपके लिए इस प्रकार को संक्रमित करता है)। दूसरे शब्दों में, यह कॉल करने वाला है जो तय करता है कि कौन सा नया प्रकार T हमारे प्रकार का दिखावा करेगा जो इस विशेषता को लागू करता है:

 let foo = Foo::new(); let bar: &Bar = foo.as_ref(); 

यहां, संकलक, bar: &Bar ज्ञान का उपयोग करते हुए bar: &Bar , AsRef<Bar> कार्यान्वयन का उपयोग as_ref() विधि को कॉल करने के लिए as_ref() , क्योंकि यह Bar का प्रकार है जो कॉलर द्वारा आवश्यक है। यह बिना यह कहे चला जाता है कि Foo प्रकार को AsRef AsRef<Bar> को लागू करना चाहिए, और इसके अलावा, यह कई अन्य AsRef<T> विकल्पों को लागू कर सकता है, जिनमें से कॉल करने वाला वांछित का चयन करता है।

संबद्ध प्रकार के मामले में, सब कुछ बिल्कुल विपरीत है। संबंधित प्रकार पूरी तरह से उन लोगों द्वारा नियंत्रित किया जाता है जो इस विशेषता को लागू करते हैं, और कॉलर द्वारा नहीं।

एक सामान्य उदाहरण एक पुनरावृत्त है। मान लीजिए कि हमारे पास एक संग्रह है, और हम इससे एक पुनरावृत्ति प्राप्त करना चाहते हैं। पुनरावृतिकर्ता को किस प्रकार के मान होने चाहिए? वास्तव में इस संग्रह में निहित एक! यह निर्धारित करने के लिए कॉल करने वाले पर निर्भर नहीं है कि पुनरावृत्त क्या लौटेगा, और पुनरावृत्ति करने वाला खुद ही बेहतर जानता है कि वह वास्तव में क्या जानता है कि कैसे लौटना है। यहाँ मानक पुस्तकालय से संक्षिप्त कोड है:

 trait Iterator { type Item; fn next(&mut self) -> Option<Self::Item>; } 

ध्यान दें कि पुनरावृत्त में एक प्रकार का पैरामीटर नहीं है जो कॉलर को यह चुनने की अनुमति देता है कि पुनरावृत्त क्या लौटना चाहिए। इसके बजाय, next() विधि से लौटाए गए मान का प्रकार संबंधित प्रकार का उपयोग करके इटेटर द्वारा निर्धारित किया जाता है, लेकिन यह नाखूनों के साथ अटक नहीं है, अर्थात। प्रत्येक पुनरावृत्ति कार्यान्वयन अपने प्रकार का चयन कर सकता है।

बंद करो। तो क्या? सभी समान है, यह स्पष्ट नहीं है कि यह सामान्य से बेहतर क्यों है। एक पल के लिए कल्पना करें कि हम संबद्ध प्रकार के बजाय सामान्य जेनेरिक का उपयोग करते हैं। पुनरावृति की विशेषता कुछ इस तरह दिखाई देगी:

 trait GenericIterator<T> { fn next(&mut self) -> Option<T>; } 

लेकिन अब, सबसे पहले, टाइप T को बार-बार हर उस जगह पर इंगित करने की आवश्यकता होती है, जहां इट्रेटर का उल्लेख किया गया है, और दूसरी बात, अब इस विशेषता को कई बार अलग-अलग प्रकारों से लागू करना संभव हो गया है, जो इट्रेटर के लिए किसी तरह अजीब लगता है। यहाँ एक उदाहरण है:

 struct MyIterator; impl GenericIterator<i32> for MyIterator { fn next(&mut self) -> Option<i32> { unimplemented!() } } impl GenericIterator<String> for MyIterator { fn next(&mut self) -> Option<String> { unimplemented!() } } fn test() { let mut iter = MyIterator; let lolwhat: Option<_> = iter.next(); // Error! Which impl of GenericIterator to use? } 

कैच देखें? हम iter.next() बिना iter.next() को केवल ले और कॉल नहीं कर सकते हैं - हमें संकलक को यह बताने की आवश्यकता है, स्पष्ट रूप से या स्पष्ट रूप से, किस प्रकार वापस किया जाएगा। और यह अजीब लग रहा है: हमें कॉल पक्ष पर क्यों, पता होना चाहिए (और संकलक को बताना चाहिए!) टाइप करने वाला इटरेटर वापस आ जाएगा, जबकि इस इटरेटर को बेहतर पता होना चाहिए कि वह किस प्रकार का रिटर्न देता है ?; और सभी क्योंकि हम एक ही MyIterator लिए एक अलग पैरामीटर के साथ दो बार MyIterator GenericIterator को लागू करने में सक्षम थे, जो कि इटरेटर शब्दार्थ के दृष्टिकोण से भी हास्यास्पद लगता है: ऐसा क्यों है कि एक ही इट्रेटर विभिन्न प्रकारों के मान लौटा सकता है?

यदि हम संबंधित प्रकार के साथ संस्करण में लौटते हैं, तो इन सभी समस्याओं से बचा जा सकता है:

 struct MyIter; impl Iterator for MyIter { type Item = String; fn next(&mut self) -> Option<Self::Item> { unimplemented!() } } fn test() { let mut iter = MyIter; let value = iter.next(); } 

यहां, सबसे पहले, कंपाइलर सही तरीके से आउटपुट का उत्पादन करेगा value: Option<String> प्रकार बिना अनावश्यक शब्दों के, और दूसरी बात, यह एक अलग रिटर्न प्रकार के साथ दूसरी बार MyIter लिए Iterator MyIter को लागू करने के लिए काम नहीं करेगा, और इस तरह सब कुछ बर्बाद कर देगा।

फिक्सिंग के लिए। एक संग्रह इस तरह के एक लक्षण को लागू कर सकता है ताकि वह खुद को पुनरावृति में बदल सके:

 trait IntoIterator { type Item; type IntoIter: Iterator<Item=Self::Item>; fn into_iter(self) -> Self::IntoIter; } 

और फिर, यहां यह संग्रह है जो यह तय करता है कि पुनरावृत्त क्या होगा, अर्थात्: एक पुनरावृत्ति जिसका वापसी प्रकार संग्रह में तत्वों के प्रकार से मेल खाता है, और कोई अन्य नहीं।

उंगलियों पर अधिक

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

मानक पुस्तकालय में गणितीय ऑपरेटरों को इसके प्रकारों (इसके अलावा, घटाव, गुणा, भाग और इसी तरह) के लिए अधिभारित करने की क्षमता है। ऐसा करने के लिए, आपको मानक पुस्तकालय से संबंधित लक्षणों में से एक को लागू करने की आवश्यकता है। यहां, उदाहरण के लिए, यह विशेषता अतिरिक्त संचालन के लिए कैसे दिखती है (फिर से, सरलीकृत):

 trait Add<RHS> { type Output; fn add(self, rhs: RHS) -> Self::Output; } 

यहां हमारे पास "इनपुट" RHS तर्क है - यह वह प्रकार है जिसके साथ हम अपने प्रकार के साथ अतिरिक्त संचालन लागू करेंगे। और एक "आउटपुट" तर्क है Add::Output - यह वह प्रकार है जो परिणाम के अतिरिक्त होगा। सामान्य मामले में, यह शब्दों के प्रकार से भिन्न हो सकता है, जो बदले में, विभिन्न प्रकारों का भी हो सकता है (नीले में स्वादिष्ट जोड़ें और नरम हो जाएं - लेकिन क्या, मैं हर समय ऐसा करता हूं)। पहला प्रकार तर्क का उपयोग करके निर्दिष्ट किया गया है, दूसरा संबंधित प्रकार का उपयोग करके निर्दिष्ट किया गया है।

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

आइए इस विशेषता को लागू करने का प्रयास करें:

 use std::ops::Add; struct Foo(&'static str); #[derive(PartialEq, Debug)] struct Bar(&'static str, i32); impl Add<i32> for Foo { type Output = Bar; fn add(self, rhs: i32) -> Bar { Bar(self.0, rhs) } } fn test() { let x = Foo("test"); let y = x + 42; //      <Foo as Add>::add(42)  x assert_eq!(y, Bar("test", 42)); } 

इस उदाहरण में, चर y का प्रकार अतिरिक्त एल्गोरिथ्म द्वारा निर्धारित किया जाता है, कॉलिंग कोड नहीं। यह बहुत अजीब होगा अगर यह संभव हो तो कुछ लिखने दें जैसे let y: Baz = x + 42 , अर्थात्, कुछ बाहरी प्रकार के परिणाम को वापस करने के लिए अतिरिक्त ऑपरेशन को मजबूर करें। यह ऐसी चीजों से है जो संबंधित प्रकार Add::Output हमें प्रेरित करता है।

कुल मिलाकर

हम जेनरिक का उपयोग करते हैं जहां हमें एक ही प्रकार के कई गुणन कार्यान्वयन करने से कोई फर्क नहीं पड़ता है, और जहां कॉल पक्ष पर एक विशिष्ट कार्यान्वयन निर्दिष्ट करना स्वीकार्य है। हम संबद्ध प्रकारों का उपयोग करते हैं जहां हम एक "कैनोनिकल" कार्यान्वयन चाहते हैं, जो स्वयं प्रकारों को नियंत्रित करता है। अंतिम अनुपात में सही अनुपात में मिलाएं और मिलाएं।

क्या सिक्का फेल हो गया? मुझे टिप्पणियों के साथ मार डालो।