🧕 ✊🏿 💲 स्वामित्व पर ध्यान केंद्रित करना ◼️ ◀️ 🥤

लगभग। अनुवादक: रिकॉर्ड १३ मई २०१४ को दिनांकित है, इसलिए कुछ विवरण, स्रोत कोड सहित, चीजों की वर्तमान स्थिति के अनुरूप नहीं हो सकते हैं। इस प्रश्न का उत्तर कि इतनी लंबी पोस्ट के अनुवाद की आवश्यकता क्यों है, इसकी सामग्री का मूल्य रूस्ट भाषा की मौलिक अवधारणाओं में से एक की समझ बनाने के लिए होगा, जैसे प्रवाह।

समय के साथ, मुझे विश्वास हो गया कि रस्ट में परिवर्तनशील और अपरिवर्तनीय स्थानीय चरों के बीच के अंतर को छोड़ना बेहतर होगा। इस मुद्दे पर कम से कम कई लोगों को संदेह है । मैं अपनी स्थिति सार्वजनिक रूप से बताना चाहता था। मैं विभिन्न उद्देश्यों को दूंगा: दार्शनिक, तकनीकी और व्यावहारिक, साथ ही वर्तमान प्रणाली के मुख्य बचाव की ओर। (ध्यान दें: मैंने इसे Rust RFC के रूप में देखा, लेकिन यह निर्णय लिया कि टोन एक ब्लॉग पोस्ट के लिए बेहतर है और मेरे पास अब इसे फिर से लिखने का समय नहीं है।)

स्पष्टीकरण

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

एक शब्द में

मैं अपरिवर्तनीय और परिवर्तनशील स्थानीय चर और नाम &mut बिंदुओं के बीच &my , &only या &uniq बीच के अंतर को दूर करना चाहूंगा ( &uniq मुझे कोई फर्क नहीं पड़ता)। यदि केवल कोई कीवर्ड mut नहीं था।

दार्शनिक मकसद

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

भिन्नता विशिष्टता का एक परिणाम बन जाती है: "आप हमेशा वह सब कुछ बदल सकते हैं जिसकी आपके पास अद्वितीय पहुंच हो। साझा डेटा आमतौर पर अपरिवर्तनीय होता है, लेकिन यदि आपको आवश्यकता है, तो आप इसे किसी प्रकार की Cell प्रकार का उपयोग करके बदल सकते हैं।"

दूसरे शब्दों में, समय के साथ, यह मेरे लिए स्पष्ट हो गया कि डेटा रेसिंग और मेमोरी सिक्योरिटी के साथ समस्याएं तब उत्पन्न होती हैं जब आपके पास उपनाम और उत्परिवर्तन दोनों का उपयोग होता है। इस समस्या को हल करने के लिए एक कार्यात्मक दृष्टिकोण उत्परिवर्तन को खत्म करना है। जंग का दृष्टिकोण एलियंस के उपयोग को दूर करना होगा। इससे हमें एक कहानी मिलती है जिसे बताया जा सकता है और यह हमें यह पता लगाने में मदद करेगा।

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

शैक्षिक मकसद

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

इसके विपरीत, एक प्रकार जैसे &my T या &only T स्पष्टीकरण को आसान बनाता है। यह एक अनूठी कड़ी है - स्वाभाविक रूप से, आप उनमें से दो को एक ही स्थान पर इंगित करने के लिए मजबूर नहीं कर सकते। और उत्परिवर्तन एक ओर्थोगोनल चीज है: यह विशिष्टता से आता है, लेकिन यह कोशिकाओं के लिए भी सही है। और &T प्रकार इसके विपरीत, एक साझा लिंक है । RFC PR # 58 समान तर्क प्रदान करता है। मैं उन्हें यहां नहीं दोहराऊंगा।

व्यावहारिक मकसद

वर्तमान में, उधारकर्ताओं के बीच एक अंतर है, जिसे या तो साझा किया जा सकता है या उत्परिवर्तित + अद्वितीय, और स्थानीय चर जो हमेशा अद्वितीय होते हैं, लेकिन परस्पर या अपरिवर्तनीय हो सकते हैं। इसका अंतिम परिणाम यह है कि उपयोगकर्ताओं को उन चीजों पर mut विज्ञापन पोस्ट करना चाहिए जो सीधे संपादन योग्य नहीं हैं।

संदर्भों का उपयोग करके स्थानीय चर नहीं बनाए जा सकते हैं

यह घटना इसलिए होती है क्योंकि लिंक स्थानीय चर के रूप में अभिव्यंजक नहीं होते हैं। सामान्य तौर पर, यह अमूर्तता को रोकता है। मुझे आपको समझाने के लिए कुछ उदाहरण देना चाहिए। कल्पना कीजिए कि मेरे पास एक पर्यावरण संरचना है जो एक पॉइंटर को एक त्रुटि काउंटर में संग्रहीत करता है:

 struct Env { errors: &mut usize }

अब मैं इस संरचना के उदाहरण बना सकता हूं (और उनका उपयोग कर सकता हूं):

 let mut errors = 0; let env = Env { errors: &mut errors }; ... if some_condition { *env.errors += 1; }

ठीक है, अब कल्पना करें कि मैं एक अलग फ़ंक्शन में env.errors को संशोधित करने वाले कोड को अलग करना चाहता हूं। मैं सोच सकता हूं कि चूंकि env चर को उत्परिवर्तित घोषित नहीं किया गया है, मैं अपरिवर्तनीय & लिंक का उपयोग कर सकता हूं:

 let mut errors = 0; let env = Env { errors: &mut errors }; helper(&env); fn helper(env: &Env) { ... if some_condition { *env.errors += 1; //  } }

लेकिन ऐसा है नहीं। समस्या यह है कि &Env एक साझा-स्वामित्व प्रकार ( अनुवादक का नोट है: जैसा कि आप जानते हैं, एक समय में एक से अधिक अपरिवर्तनीय वस्तु संदर्भ मौजूद हो सकते हैं ), और इसलिए env.errors एक ऐसे स्थान में प्रकट होता है जो env ऑब्जेक्ट को अलग से env.errors करने की अनुमति देता है। इस कोड को काम करने के लिए, मुझे env को उत्परिवर्तित घोषित करना होगा &mut संकलक को बताने के लिए &mut लिंक ( अनुवादक नोट: &mut ) का उपयोग करना होगा, जो कि env स्वामित्व में अद्वितीय है, क्योंकि एक समय में केवल एक ही परिवर्तनशील वस्तु संदर्भ मौजूद हो सकता है और डेटा दौड़ को बाहर रखा गया है, लेकिन उत्परिवर्ती क्योंकि आप एक अपरिवर्तनीय वस्तु के लिए एक परस्पर संदर्भ नहीं बना सकते हैं ):

 let mut errors = 0; let mut env = Env { errors: &mut errors }; helper(&mut env);

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

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

क्लोजर के लिए चेकिंग टाइप करें

हमें बंद होने के मामले में इस सीमा के आसपास जाना था। क्लोज़र ज्यादातर Env जैसी संरचनाओं में खुले हैं , लेकिन काफी नहीं। ऐसा इसलिए है क्योंकि मैं चाहता हूं कि स्थानीय वैरिएबल को mut घोषित न किया जाए, अगर वे किसी क्लोजर में &mut माध्यम से उपयोग किए जाते हैं। दूसरे शब्दों में, उदाहरण के लिए कुछ कोड लें:

 fn foo(errors: &mut usize) { do_something(|| *errors += 1) }

क्लोजर का वर्णन करने वाला एक एक्सप्रेशन वास्तव में Env संरचना का एक उदाहरण बना देगा:

 struct ClosureEnv<'a, 'b> { errors: &uniq &mut usize }

&uniq लिंक देखें। यह कुछ ऐसा नहीं है जो अंतिम उपयोगकर्ता दर्ज कर सकता है। इसका मतलब है "अद्वितीय लेकिन जरूरी नहीं कि परस्पर" सूचक। यह टाइप चेकिंग पास करने के लिए आवश्यक है। यदि उपयोगकर्ता ने इस संरचना को मैन्युअल रूप से लिखने की कोशिश की है, तो उसे लिखना होगा &mut &mut usize करना होगा, जिससे बदले में errors को mut errors: &mut usize रूप में घोषित किया जाना होगा mut errors: &mut usize ।

बंद क्लोजर और प्रक्रियाएं

मैं भविष्यवाणी करता हूं कि यह प्रतिबंध अनपैक किए गए बंदों के लिए एक समस्या है। मुझे उस डिज़ाइन के बारे में विस्तार से बताएं जिस पर मैं विचार कर रहा था। मूल रूप से, यह विचार था कि अभिव्यक्ति || कुछ नए संरचनात्मक प्रकारों के बराबर है जो लक्षणों में से एक को लागू करता है Fn :

 trait Fn<A, R> { fn call(&self, ...); } trait FnMut<A, R> { fn call(&mut self, ...); } trait FnOnce<A, R> { fn call(self, ...); }

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

 fn foo(&self, closure: FnMut<usize, usize>) { ... } fn foo<T: FnMut<usize, usize>>(&self, closure: T) { ... }

हम ... शायद वाक्यविन्यास को ठीक करना चाहते हैं, शायद FnMut(usize) -> usize तरह चीनी जोड़ें FnMut(usize) -> usize , या सहेजें - usize | -> इत्यादि। यह इतना महत्वपूर्ण नहीं है, यह महत्वपूर्ण है कि हम मूल्य से समापन को पारित करेंगे। कृपया ध्यान दें कि वर्तमान डीएसटी (डायनामिक-साइज़्ड टाइप्स) नियमों के अनुसार, यह एक प्रकार से मान के रूप में FnMut<usize, usize> तर्क के रूप में पारित करने के लिए अनुमत है, इसलिए तर्क FnMut<usize, usize> एक वैध FnMut<usize, usize> है और कोई समस्या नहीं है।

एक तरफ : यह परियोजना पूरी नहीं है, और मैं एक अलग संदेश में सभी विवरणों का वर्णन करूंगा।

समस्या यह है कि एक &mut को कॉल करने के लिए एक &mut लिंक की आवश्यकता होती है। चूँकि क्लोज़र वैल्यू द्वारा पास किया जाता है, इसलिए उपयोगकर्ताओं को फिर से mut लिखना होगा, जहाँ वह जगह से बाहर दिखता है:

 fn foo(&self, mut closure: FnMut<usize, usize>) { let x = closure.call(3); }

FnMut उदाहरण में भी यही समस्या है: वास्तव में यहां क्या होता है, FnMut केवल एक अद्वितीय लिंक चाहती है, लेकिन चूंकि यह टाइप सिस्टम का हिस्सा नहीं है, इसलिए यह एक परिवर्तनशील लिंक का अनुरोध करता है।

अब हम शायद इसे अलग-अलग तरीकों से प्राप्त कर सकते हैं। एक विकल्प जो हम कर सकते थे || वाक्य-विन्यास एक "कुछ संरचनात्मक प्रकार" में विस्तार नहीं करेगा, बल्कि एक "संरचनात्मक प्रकार या एक संरचनात्मक प्रकार के लिए एक संकेतक, जैसा कि प्रकार के अनुमान से निर्धारित होता है" में विस्तारित नहीं होगा। इस मामले में, कॉलर लिख सकता है:

 fn foo(&self, closure: &mut FnMut<usize, usize>) { let x = closure.call(3); }

मैं यह नहीं कहना चाहता कि यह दुनिया का अंत है। लेकिन यह बढ़ती हुई विकृतियों में एक और कदम है जिसे हमें स्थानीय चरों और संदर्भों के बीच इस अंतर को बनाए रखने के लिए गुजरना चाहिए।

अन्य एपीआई भागों

मैंने एक संपूर्ण अध्ययन नहीं किया, लेकिन, निश्चित रूप से, यह अंतर कहीं और से समाप्त हो गया। उदाहरण के लिए, Socket से पढ़ने के लिए, मुझे एक अद्वितीय सूचक की आवश्यकता है, इसलिए मुझे इसे परिवर्तनशील घोषित करना होगा। इसलिए, कभी-कभी यह काम नहीं करता है:

 let socket = Socket::new(); socket.read() // :

स्वाभाविक रूप से, मेरे सुझाव के अनुसार, ऐसा कोड ठीक काम करेगा। यदि आप &Socket से पढ़ने का प्रयास करते हैं, तब भी आपको एक त्रुटि संदेश प्राप्त होगा, लेकिन तब यह कुछ ऐसा पढ़ेगा जैसे "साझा लिंक के लिए एक अद्वितीय लिंक बनाना असंभव है", जिसे मैं व्यक्तिगत रूप से अधिक समझने योग्य मानता हूं।

लेकिन क्या हमें सुरक्षा की जरूरत नहीं है?

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

mut के आवेदन के वर्तमान नियमों में जो अर्थ मैं देख रहा हूं, और मैं इस बात से इनकार नहीं करूंगा कि इसका मूल्य है, मुख्य रूप से यह है कि वे इरादा घोषित करने में मदद करते हैं। यही है, जब मैं कोड पढ़ता हूं, मुझे पता है कि कौन से चर को फिर से असाइन किया जा सकता है। दूसरी ओर, मैं C ++ कोड पढ़ने में भी बहुत समय बिताता हूं और, स्पष्ट रूप से, मैंने कभी नहीं देखा कि यह एक बड़ी ठोकर है। (जब मैं जावा, जावास्क्रिप्ट, पायथन, या रूबी में पढ़ने का समय बिताता हूं तो वही होता है।)

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

विकल्प

मुझे वर्तमान प्रणाली के तीन विकल्प दिखाई देते हैं:

एक मैंने प्रस्तुत किया है जहाँ आप केवल "उत्परिवर्तन" को फेंक देते हैं और केवल विशिष्टता को ट्रैक करते हैं।
एक जहां आपके पास तीन संदर्भ प्रकार हैं: & , &uniq और &mut । (जैसा कि मैंने लिखा है, यह वास्तव में एक प्रकार की प्रणाली है जो आज हमारे पास है, कम से कम एक उधार लेने वाले चेकर के दृष्टिकोण से।)
एक अधिक कठोर विकल्प, जिसमें गैर-म्यूट चर हमेशा अलग माने जाते हैं। इसका मतलब होगा कि आपको लिखना होगा:
```
 let mut errors = 0; let mut p = &mut errors; // ,  `p`   ,  `mut`. *p += 1; 
```
आपको p को mut घोषित करने की आवश्यकता है, क्योंकि अन्यथा चर को अलग-अलग माना जाएगा, भले ही यह एक स्थानीय चर हो, और इसलिए *p बदलने की अनुमति नहीं है। इस योजना में जो अजीब है वह यह है कि स्थानीय चर अलग-अलग स्वामित्व की अनुमति नहीं देते हैं, और हम सुनिश्चित करने के लिए जानते हैं, क्योंकि जब आप इसका उपनाम बनाने की कोशिश करेंगे, तो यह स्थानांतरित हो जाएगा, विध्वंसक उस पर शुरू हो जाएगा, आदि। यही है, हमारे पास अभी भी "स्वामित्व" की अवधारणा है, जो इससे अलग है "अलग स्वामित्व की अनुमति नहीं देता है।"

दूसरी ओर, यदि हमने इस प्रणाली का वर्णन किया है, तो यह कहते हुए कि उत्परिवर्तन को साझा स्वामित्व के बारे में हकलाने के बिना, &mut पॉइंटर्स के माध्यम से विरासत में मिला है, यह समझ में आ सकता है।

इन तीनों में से, मैं निश्चित रूप से नंबर 1 को पसंद करता हूं। यह सबसे सरल है, और अब मुझे सबसे अधिक दिलचस्पी है कि हम इसके चरित्र को संरक्षित करके रस्ट को कैसे सरल बना सकते हैं। अन्यथा, हम अभी जो हमारे पास है उसे वरीयता देते हैं।

निष्कर्ष

मूल रूप से, मुझे लगता है कि परिवर्तनशीलता के बारे में मौजूदा नियमों का कुछ मूल्य है, लेकिन वे महंगे हैं। वे एक प्रकार की बहती अमूर्तता हैं: अर्थात, वे एक सरल कहानी बताते हैं, जो वास्तव में अधूरी होती है। यह भ्रम की ओर जाता है जब लोग एक प्रारंभिक समझ से आगे बढ़ते हैं, जिसमें &mut दर्शाता है कि परिवर्तनशीलता कैसे काम करती है, एक पूर्ण समझ के लिए: कभी-कभी mut को सुनिश्चित करने के लिए केवल mut आवश्यकता होती है, और कभी-कभी उत्परिवर्तन को बिना mut खोजशब्द के प्राप्त किया जाता है।

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

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

मुझे नहीं लगता कि यह इसके लायक है।

स्वामित्व पर ध्यान केंद्रित करना