टेस्ट बनाम प्रकार - जंग संस्करण

कुछ दिनों पहले 0xd34df00d ने कुछ फ़ंक्शन के बारे में संभावित जानकारी का वर्णन करते हुए लेख का अनुवाद प्रकाशित किया है यदि हम इसे "ब्लैक बॉक्स" के रूप में उपयोग करते हैं, तो इसके कार्यान्वयन को पढ़ने की कोशिश नहीं कर रहे हैं। बेशक, यह जानकारी भाषा से भाषा में काफी भिन्न है; मूल लेख में, चार मामलों पर विचार किया गया था:

• अजगर - गतिशील टाइपिंग, हस्ताक्षर से लगभग कोई जानकारी नहीं, कुछ संकेत परीक्षणों द्वारा प्राप्त किए जाते हैं;
• सी - कमजोर स्थिर टाइपिंग, थोड़ी अधिक जानकारी;
• हास्केल - मजबूत स्थैतिक टाइपिंग, डिफ़ॉल्ट रूप से शुद्ध कार्यों के साथ, बहुत अधिक जानकारी;
• इदरीस - आश्रित टाइपिंग, कंपाइलर फ़ंक्शन को सही साबित कर सकता है।

"यहां सी है और हस्केल है, और जंग के बारे में क्या है?" - निम्नलिखित चर्चा में यह पहला प्रश्न था। जवाब यहाँ है।

आइए पहले कार्य को याद करते हैं:

मूल्यों और मूल्य की सूची को देखते हुए, सूची में मूल्य का सूचकांक लौटाएं या संकेत दें कि यह सूची में मौजूद नहीं है।

अगर कोई यह सब नहीं पढ़ना चाहता है, तो कोड उदाहरण रस्ट खेल के मैदान में प्रदान किए जाते हैं।
नहीं तो चलिए शुरू करते हैं!

सरल खोज

पहला दृष्टिकोण लगभग भोले हस्ताक्षर वाला होगा, केवल कुछ मुहावरेदार तत्वों में सी कोड से अलग होगा:

fn foo(x: &[i32], y: i32) -> Option<usize> { // Implementation elided } 

हम इस फ़ंक्शन के बारे में क्या जानते हैं? खैर, वास्तव में - बहुत ज्यादा नहीं। बेशक, Option<usize> एक वापसी मान के रूप में जो कुछ भी सी द्वारा प्रदान किया गया है उस पर एक महान सुधार है, लेकिन फ़ंक्शन शब्दार्थ के बारे में कोई जानकारी नहीं है। विशेष रूप से, हमारे पास अनुपस्थित होने के दुष्प्रभावों की कोई गारंटी नहीं है और किसी भी तरह से वांछित व्यवहार की जांच करने का कोई तरीका नहीं है।

क्या कोई टेस्ट इसमें सुधार कर सकता है? यहां देखें:

 #[test] fn test() { assert_eq!(foo(&[1, 2, 3], 2), Some(1)); assert_eq!(foo(&[1, 2, 3], 4), None); } 

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

जेनरिक का प्रयोग करें, ल्यूक!

लेकिन क्या यह कोई अच्छा है कि हमें केवल 32-बिट हस्ताक्षरित संख्याओं का उपयोग करना है? इसे ठीक करना:

 fn foo<El>(x: &[El], y: El) -> Option<usize> where El: PartialEq, { // Implementation elided } 

खैर, यह कुछ है! अब हम किसी भी तुलनीय प्रकार के तत्वों से मिलकर कोई भी टुकड़ा ले सकते हैं। स्पष्ट बहुरूपता लगभग हमेशा बेहतर होता है कि निहित (हैलो, पायथन) और लगभग हमेशा बेहतर होता है फिर कोई बहुरूपता (हेलो, सी), बिल्कुल नहीं?

हालाँकि, यह फ़ंक्शन अप्रत्याशित रूप से इस परीक्षा को पास कर सकता है:

 fn refl<El: PartialEq + Copy>(el: El) -> Option<usize> { foo(&[el], el) // should always return Some(0), right? } #[test] fn dont_find_nan() { assert_eq!(refl(std::f64::NAN), None); } 

यह एक लापता बिंदु पर संकेत देता है, क्योंकि विनिर्देश refl फ़ंक्शन चाहता है, वास्तव में, हमेशा Some(0) वापस करने के लिए। बेशक, यह सब सामान्य रूप से आंशिक-समतुल्य प्रकार के विशिष्ट व्यवहार और विशेष रूप से तैरने के कारण होता है।
शायद हम इस समस्या से छुटकारा पाना चाहते हैं? तो, हम एल प्रकार पर बंधे को कस देंगे:

 fn foo<El>(x: &[El], y: El) -> Option<usize> where El: Eq, { // Implementation elided } 

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

 fn foo<'a, El: 'a>(x: impl IntoIterator<Item = &'a El>, y: El) -> Option<usize> where El: Eq, { // Implementation elided } 

पहले की तरह, लेकिन थोड़ा और सख्त

लेकिन अब, शायद हमें कुछ और गारंटी चाहिए। या हम स्टैक पर काम करना चाहते हैं (और Vec उपयोग नहीं कर सकते हैं), लेकिन हर संभव सरणी आकार के लिए हमारे कोड को सामान्य बनाने की आवश्यकता है। या हम प्रत्येक ठोस सरणी आकार के लिए अनुकूलित फ़ंक्शन को संकलित करना चाहते हैं।

वैसे भी, हम एक सामान्य सरणी की जरूरत है - और वास्तव में प्रदान करते हुए, जंग में एक टोकरा है ।

अब, यहाँ हमारा कोड है:

 use generic_array::{GenericArray, ArrayLength}; fn foo<El, Size>(x: GenericArray<El, Size>, y: El) -> Option<usize> where El: Eq, Size: ArrayLength<El>, { // Implementation elided } 

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

लेकिन हम और आगे बढ़ सकते हैं।

टाइप-स्तरीय अंकगणित

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

ऐसा लगता है कि निर्भर प्रकार - या उनके जैसे कुछ - ऐसी गारंटी के लिए आवश्यक हैं, और हम रस्ट से समान नहीं प्राप्त कर सकते हैं, है ना?

टाइपिन से मिलें । इसका उपयोग करते हुए, हम अपने कार्य को निम्नलिखित तरीके से लिख सकते हैं:

 use generic_array::{ArrayLength, GenericArray}; use typenum::{IsLess, Unsigned, B1}; trait UnsignedLessThan<T> { fn as_usize(&self) -> usize; } impl<Less, More> UnsignedLessThan<More> for Less where Less: IsLess<More, Output = B1>, Less: Unsigned, { fn as_usize(&self) -> usize { <Self as Unsigned>::USIZE } } fn foo<El, Size>(x: GenericArray<El, Size>, y: El) -> Option<Box<dyn UnsignedLessThan<Size>>> where El: Eq, Size: ArrayLength<El>, { // Implementation elided } 

"यह काला जादू क्या है?" - आप पूछ सकते हैं। और आप सही हैं: टाइपेनम एक काला जादू है, और इसका उपयोग करने का कोई भी प्रयास और भी अधिक जादू है।

लेकिन यह फ़ंक्शन हस्ताक्षर काफी ठोस है।

• यह लंबाई के आकार और एक और एल के साथ एल की एक सरणी लेता है।
• यह एक विकल्प देता है, जो, यदि यह कुछ है,
  
  • एक लक्षण वस्तु रखता है, जो UnsignedLessThan<Size> विशेषता पर आधारित है;
  • और UnsignedLessThan<T> जहां भी IsLess<T> और IsLess<T> लागू किया गया है और IsLess<T> B1 देता है, अर्थात् सत्य।

दूसरे शब्दों में, यह फ़ंक्शन अहस्ताक्षरित पूर्णांक को सरणी आकार से कम वापस करने की गारंटी है (कड़ाई से बोलते हुए, यह विशेषता ऑब्जेक्ट लौटाता है, लेकिन हम as_usize विधि को कॉल कर सकते हैं और पूर्णांक प्राप्त कर सकते हैं)।

मैं अब दो प्रमुख कैवेट की बात कर सकता हूं:

1. हमें प्रदर्शन का नुकसान हो सकता है। यदि किसी तरह यह फ़ंक्शन प्रोग्राम के "हॉट" पथ पर होगा, तो निरंतर गतिशील डिस्पैच पूरी प्रक्रिया को धीमा कर सकता है। यह वास्तव में एक बड़ी चिंता नहीं हो सकती है, लेकिन एक और है:
2. इस फ़ंक्शन को संकलित करने के लिए, हमें या तो इसके अंदर इसकी शुद्धता का प्रमाण लिखना होगा, या कुछ unsafe साथ टाइप सिस्टम को ट्रिक करना होगा। पूर्व काफी जटिल है, और बाद वाला सिर्फ धोखा दे रहा है।

निष्कर्ष

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

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