Rust: केवल परिवर्तनशील स्थानीय लोगों के लिए var कीवर्ड

मुझे कबूल करना होगा, मैंने पहले सोचा था कि हमें एक ही कीवर्ड का उपयोग म्यूटेबल वर्र्स और म्यूटेबल फ़ील्ड के लिए करना चाहिए, लेकिन var थोड़े 'अच्छी तरह से पढ़ता है (हालांकि मुझे नापसंद नहीं है let mut )

मुझे लगता है कि यह एक विशेषता है कि एक परिवर्तनीय चर घोषित करना एक अपरिवर्तनीय एक से थोड़ा अधिक बोझिल है। मैं प्रोग्रामर को "सुसंगत" होने के लिए केवल "var" का उपयोग करते हुए देख सकता हूं या क्योंकि "var" अधिक शक्तिशाली होगा (यदि आप बाद में उत्परिवर्तित करने का निर्णय लेते हैं तो इसे बदलने की आवश्यकता नहीं है)। फिर आप कुल मिलाकर कम पठनीय कोड के साथ समाप्त होते हैं।

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

एक तरफ मुझे यह पसंद है, क्योंकि यह इस रूप से दृश्य अस्पष्टता को हटा देगा:

let mut x = 4,
    y = 8;  // is y mutable or not?

लेकिन मैं सिल्वान के पक्ष में हूं। उत्परिवर्तनों को घोषित करने के लिए वास्तव में _ugly_ होने की आवश्यकता नहीं है, लेकिन मुझे लगता है कि यह समझ में आता है कि अगर वे केवल एक कीस्ट्रोक द्वारा अपरिवर्तनीय से बनाने के लिए कभी-कभी थोड़ा कम सुविधाजनक होते हैं। सक्रिय करने वाले कीवर्ड को भी विशिष्ट होने की आवश्यकता है, और (IMO) var का व्यापक रूप से एक सामान्य चर घोषणा कीवर्ड के रूप में उपयोग किया जाता है, विशेष रूप से एक ऐसी भाषा में परिवर्तनशीलता को व्यक्त करने के लिए जो अपरिवर्तनीयता-बाय-डिफॉल्ट पर गर्व करती है। और गरीब C# प्रोग्रामर्स के बारे में सोचें, जिनके लिए var हमारा let !

मुझे अभी भी एक कीवर्ड के साथ let mut को बदलने का विचार पसंद है, ताकि ऊपर दिए गए कोड स्निपेट को संबोधित किया जा सके, लेकिन क्या कोई नया कीवर्ड पेश करने का कोई कारण है जब mut ही पर्याप्त होगा #1273 में मूल प्रस्ताव?

@pcwalton ने केवल mut का उपयोग करने के साथ एक समस्या की ओर इशारा किया: रिकॉर्ड अक्षर और ब्लॉक अभिव्यक्तियों के साथ एक अस्पष्टता है जिसे हल करने के लिए मनमानी लुकहेड की आवश्यकता होती है।

{ mut x: int ...

रिकॉर्ड शाब्दिक, या स्थानीय चर के साथ ब्लॉक?

मैं बहुत सारे प्रोग्रामर को यह सीखते हुए देख सकता था कि var यह है कि आप रस्ट में वेरिएबल कैसे घोषित करते हैं, और let का उपयोग बिल्कुल भी नहीं करते हैं। आखिरकार, var यह है कि आप जावास्क्रिप्ट जैसी भाषाओं में स्थानीय चर कैसे घोषित करते हैं। मुझे लगता है कि इस प्रस्ताव के बारे में यह एक अच्छी बात है।

मैंने कल किसी को यह कहते हुए सुना कि अब let और var लंबाई समान होगी, जो संरेखण के लिए अच्छा होगा।

मैं कुछ हद तक उदासीन हूं, लेकिन मैं कुछ हद तक var पसंद करता हूं, क्योंकि यह छोटा है। जैसा कि मैं देख रहा हूं, परिवर्तनशीलता को कष्टप्रद बनाना एक वांछनीय लक्ष्य नहीं है। (वास्तव में, मुझे लगता है कि प्रोग्रामिंग भाषा की भूमिका कुछ भी परेशान करने के लिए नहीं होनी चाहिए-बस _clear_, जो एक ही बात नहीं है।)

जबकि मैं अभी भी let और var एक साथ उपयोग करने से सावधान हूं (बस जावास्क्रिप्ट की तरह, लेकिन 100% अलग), यह एक समस्या से बहुत कम होगा यदि चर का पता लगाने के लिए एक लिंट पास था जिन्हें उत्परिवर्तनीय घोषित किया जाता है लेकिन वास्तव में कभी भी उत्परिवर्तित नहीं किया जाता है।

परिवर्तनशीलता को इस प्रकार का हिस्सा बनाने की योजना है। क्या यह स्थानीय लोगों को प्रभावित करता है और इसे अप्रासंगिक बनाता है?

कैसा रहेगा:

val x = ... // immutable (val-ue)
var y = ... // mutable (var-iable)

जैसे स्कैला में।

मुझे लगता है कि @brson सही है और एक बार जब हम mut को एक प्रकार में ले जाते हैं, तो यह समस्या गायब हो जाती है, यानी आपको let x = mut 10;

इस मुद्दे को अभी के लिए बंद करना; अगर आपको लगता है कि मैं गलत हूं तो फिर से खोलें!

मैं इस बारे में निश्चित नहीं हूँ। मुझे म्यूट को प्रकार में ले जाने का विचार पसंद है, लेकिन मुझे नहीं पता कि यह एक "किया गया सौदा" है --- वहां अजीब अजीबता हो सकती है। किसी भी मामले में, मैंने कभी नहीं सोचा था कि कोई let x = mut 5 लिख सकता है, मैंने हमेशा मान लिया था कि आप आज की तरह ही let mut x = 5 लिखेंगे; एक चर के प्रकार का "परिवर्तनशीलता-नेस" जिस तरह से घोषित किया गया था, उससे आएगा, न कि उसे सौंपा जा रहा मूल्य।

अन्यथा करने के लिए यह प्रतीत होता है कि यदि आपके पास x प्रकार का [mut int] और आप let y = x[0] लिखते हैं तो y उत्परिवर्तनीय है? या कुछ और? यह अवांछनीय लगता है।

@Dretch मुझे वैल/var पसंद नहीं है क्योंकि वे पर्याप्त रूप से अलग नहीं हैं, हालांकि

मैं डिफ़ॉल्ट रूप से var का उपयोग करना सीख रहे लोगों के बारे में @eholk की चिंता साझा करता mut टाइप करता हूं। यह यकीनन अच्छा व्यवहार है कि आप var/let विभाजन के साथ कम इच्छुक होंगे - var और let टाइप करना समान रूप से कठिन है लेकिन आप let mut भी टाइप नहीं कर सकते हैं let टाइप किए।

लेकिन मेरी कोई प्राथमिकता नहीं है और मैं इसकी सराहना करता हूं जब मैं तीन-वर्ण वाले कीवर्ड से शुरू होने वाले बयानों के कार्यों को पूरी तरह से लिख सकता हूं।

@nikomatsakis विशेष रूप से, यह मेरे लिए समझ में आता है कि एकल-असाइनमेंट के नियम प्रकार के बजाय घोषणा की परिवर्तनशीलता से आना चाहिए। प्रकार के आधार पर असाइनमेंट नियमों को सूक्ष्मता से बदलना मेरे लिए अजीब है।

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

डेव

क्या यह वास्तव में भयानक है यदि प्रोग्रामर अपने सभी चरों को परिवर्तनशील घोषित करते हैं? ऐसा लगता है कि यह दुनिया का अंत नहीं है अगर हमारे पास जंग प्रोग्रामर का एक सेट है जो सिर्फ var सोचता है कि आप चर कैसे घोषित करते हैं, और दूसरा सेट जो ज्यादातर समय let का उपयोग करना समझता है और जरूरत पड़ने पर var । पहले रस्ट प्रोग्रामर के रूप में, हम let और var सही उपयोग करने के पक्ष में मिसाल कायम कर सकते हैं।

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

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

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

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

@ssylvan ओह, मैं उस बिंदु को समझता हूं, यह सिर्फ डिग्री का सवाल है, और व्यापार-संतुलन का है। हम पहले से ही डेटा संरचनाओं की अपरिवर्तनीयता को बढ़ावा देते हैं, और अपरिवर्तनीय क्षेत्रों की तुलना में आईएमओ अपरिवर्तनीय स्थानीय लोगों को बढ़ावा देने के लिए कम महत्वपूर्ण हैं। (विशेष रूप से, IINM के बाद से, हम परिवर्तनशील स्थानीय लोगों को हीप क्लोजर में भागने की अनुमति नहीं देते हैं।) और कॉलम काउंट को बदले बिना let और var बीच रिफैक्टर करने की क्षमता का नुकसान इसके लाभ से अधिक है अपरिवर्तनीय स्थानीय लोगों को बढ़ावा देना। मापना मुश्किल है, इसलिए मुझे लगता है कि यह सिर्फ मेरी भावना है।

डेव

वैसे उस स्थिति में कम से कम "लेट फू = म्यूट बार" या "लेट फू: = बार" के रूप में "लेट म्यूट फू = बार" के विपरीत पहला टोकन लाइन अप होगा। संभावित रूप से परिवर्तनीय नाम परिवर्तनीय लंबाई का होगा, इसलिए शेष कथन पर अतिरिक्त संशोधक से बचना इतना महत्वपूर्ण नहीं है।

ओह हे, मैं := विचार के लिए थोड़े आंशिक हूं।

डेव

दूसरे विचार पर, पास्कल स्थायी रूप से अस्वस्थ है। मैं इसे वापिस लेता हूँ। :)

डेव

साथ ही, let foo := bar कुछ इस तरह से रोकता है:

let mut foo;
foo = bar;

मैंने पाया है कि पैटर्न कभी-कभी उपयोगी होता है, हालांकि ऐसा लगता है कि एक ही पैटर्न लिखने का शायद हमेशा एक और तरीका होता है।

@eholk मुझे नहीं लगता कि यह इसे रोकता है। लेकिन मुझे अभी भी लगता है कि यह लगभग किसी भी मुख्यधारा की भाषा के प्रोग्रामर के लिए बहुत अजीब लगेगा।

डेव

:= , टाइप-अनुमानित असाइनमेंट को इंगित करने के लिए गो इसका उपयोग करता है (हालांकि यह अभी तक एक मुख्यधारा की भाषा नहीं है)। लेकिन मैं एक नज़र में दो रूपों के बीच अंतर करने में कठिनाई का अनुमान लगा सकता हूं:

let foo = "hello";
let foo := "hell";

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

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

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

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

(सभी लेट्स शुरू में परिवर्तनशील थे, लेकिन हमारे पास कोई पर्यावरण कैप्चर नहीं था, केवल बाइंड। अब हमारे पास कोई बाइंड नहीं है, केवल एनवी कैप्चर है। टोमायटो, टोमहतो।)

मेरा मानना ​​​​है कि म्यूटेबल को अब पूरी तरह से कब्जा नहीं किया जा सकता है।

@graydon सही है कि दो मूल प्रेरणाएँ थीं। हालांकि केवल एक अभी भी प्रासंगिक है। दो प्रेरणाएँ थीं:

• एक fn@ में परिवर्तनशील चरों का निहित "बाय-कॉपी" कैप्चर
• यह समझना कि कौन सा डेटा परिवर्तनशील है और क्या उधार के लिए नहीं है

यह पता चला है कि उत्तरार्द्ध अब प्रासंगिक नहीं है। परिवर्तनशील/अपरिवर्तनीय चरों का उपयोग व्यवहार में बहुत कच्चा था इसलिए उधार के पास एक चर "अस्थायी रूप से" उधार लेने का विचार है --- एक परिवर्तनीय चर को एक अपरिवर्तनीय पीटीआर के साथ उधार लिया जा सकता है जब तक कि सूचक में होने पर चर को संशोधित नहीं किया जाता है दायरा।

हम शायद केवल परिवर्तनशील/अपरिवर्तनीय स्थानीय लोगों के विचार को हटा सकते हैं और पुराने नियम पर वापस जा सकते हैं --- सब कुछ परिवर्तनशील है। हम तब चेतावनियां जारी कर सकते हैं जब क्लोजर बनने के बाद एक वेरिएबल जो एक क्लोजर में निहित रूप से कॉपी किया गया है, संशोधित किया गया है।

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

@Dretch मुझे "वैल" और "var" कुंजी शब्दों के साथ

मुझे पसंद है कि कैसे वर्तमान वाक्यविन्यास उत्परिवर्तनों को एक गले में अंगूठे की तरह चिपकाने का कारण बनता है; यह कोड को स्कैन करना आसान बनाता है। उस संबंध में val और var बहुत समान लगते हैं। इसका मतलब यह नहीं है कि mutables बिल्कुल _must_ बाहर रहते हैं, लेकिन खोजशब्दों को दृष्टिगत रूप से अलग रखना उपयोगिता का एक महत्वपूर्ण पहलू है।

मैं समझता हूं कि परिवर्तनशील खेतों को जंग से हटाया जा रहा है। क्या इसका मतलब यह है कि mut उपयोग let mut बजाय किया जा सकता है क्योंकि रिकॉर्ड/वेरिएबल-इन-ब्लॉक अस्पष्टता गायब हो जाएगी?

इसके अलावा, मेरा मानना ​​​​है कि संरचनात्मक रिकॉर्ड जा रहे हैं, जो अस्पष्टता को दूर करते हैं, भले ही परिवर्तनशील क्षेत्र बने रहें।

@Dretch यह सच है कि परिवर्तनशील क्षेत्र अपने रास्ते पर हैं, और संरचनात्मक रिकॉर्ड पहले ही चले गए हैं।

मैं ज्यादातर इस मुद्दे के प्रति उदासीन हूं, हालांकि मैं यह बताना चाहूंगा कि यह _might_ mut लिए अपने आप में एक घोषणा कीवर्ड होने के लिए समझ में आता है (जैसा कि ड्रेच प्रस्तावित करता है), ठंड/विगलन के मामले में . आज की तुलना करें:

let foo = 1;  // immutable
/* 10,000 lines of code here */
let mut foo = foo;  // we're making foo mutable, totally understandable
/* 10,000 lines of code here */
let foo = foo;  // potential wtf

प्रस्ताव के साथ:

let foo = 1;  // immutable
/* 10,000 lines of code here */
mut foo = foo;  // a mutable foo, no problems here
/* 10,000 lines of code here */
let foo = foo;  // slightly less of a potential for wtf, since we officially have two declaration forms

हालांकि मैं भी इस तरह महसूस जंग-वाद होगा असमान था "mut के अभाव अचल स्थिति का तात्पर्य", क्योंकि हम अभी भी लेखन होगी let foo = 1; बल्कि सिर्फ तुलना में foo = 1; (उत्तरार्द्ध रूप जाहिर है घोषणा के लिए अवांछनीय)।

कोटलिन val और var का भी उपयोग करता है।

मुझे नहीं लगता कि हम यह परिवर्तन करने जा रहे हैं, लेकिन मैं मील के पत्थर 1 के लिए नामांकित करूंगा, अच्छी तरह से परिभाषित, ताकि हम इसे सुलझा सकें।

आम सहमति ऐसा नहीं करना है, क्योंकि यह म्यूट को पैटर्न बाइंडिंग में ले जाने के साथ असंगत है। समापन।