क्या यह #25609 तक बंद है?

@Munksgaard जो सिर्फ संकलक AFAIK को समर्थन जोड़ता है। Stdlib में बहुत सारे कार्य हैं जिन्हें const fn में बदलने और टूटने के लिए परीक्षण करने की आवश्यकता है। मुझे नहीं पता कि इसमें क्या प्रगति हुई है।

मुझे उम्मीद है कि इसे std::ptr::null() और null_mut() पर लागू किया जाएगा ताकि हम $#$3 0usize as *mut _ #$ का सहारा लिए बिना static mut *MyTypeWithDrop को इनिशियलाइज़ करने के लिए उनका उपयोग कर सकें।

संपादित करें: हटा दिया गया क्योंकि यह विषय से बाहर था

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

यह अब अंतिम स्थिरीकरण के लिए ट्रैकिंग समस्या है।

https://github.com/rust-lang/rust/issues/29107 बंद कर दिया गया है।

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

तदनुसार, क्या इसकी स्थिरीकरण स्थिति का पुनर्मूल्यांकन किया जा सकता है?

मुझे इसमें कोई संदेह नहीं है कि const fn अपने वर्तमान सीमित रूप में भी उपयोगी कार्यक्षमता होगी, लेकिन आदर्श रूप से इस पथ पर आगे बढ़ने से पहले मैं जो चाहता हूं, वह उन लोगों के लिए होगा जो " const fn दृष्टिकोण" के बारे में सोचने और अपने पसंदीदा एंडगेम को स्पष्ट करने के लिए। यदि हम सबसे स्पष्ट तरीके से उपयोगी-प्रतीत होने वाली कार्यक्षमता को लगातार जोड़ते रहते हैं, तो मुझे यह बहुत संभव लगता है कि हम अंततः C++ के constexpr डिज़ाइन की संपूर्णता को कमोबेश कॉपी कर लेंगे। क्या ऐसा कुछ है जिसमें हम सहज हैं? यहां तक ​​कि अगर हम हां कहते हैं, तो मैं बेहतर यह होगा कि हम समय के साथ छोटे कदमों के साथ, कम से कम प्रतिरोध के मार्ग के रूप में, जब तक कि यह अपरिहार्य न हो जाए, तब तक हम उस रास्ते को स्पष्ट रूप से चुनें।

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

@ग्लेभोएर्ल

मुझे संदेह नहीं है कि कॉन्स्ट एफएन अपने वर्तमान सीमित रूप में भी उपयोगी कार्यक्षमता होगी, लेकिन इस रास्ते पर आगे बढ़ने से पहले आदर्श रूप से मुझे जो पसंद आएगा, वह उन लोगों के लिए होगा जो "कॉन्स्ट एफएन दृष्टिकोण" के पक्ष में होंगे। उनके पसंदीदा एंडगेम के बारे में सोचें और स्पष्ट करें ... मुझे ऐसा लगता है कि हम अंततः सी ++ के कॉन्स्टेक्स डिज़ाइन की संपूर्णता को कम या ज्यादा कॉपी कर लेंगे।

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

@eddyb और मैंने हाल ही में एक ऐसी योजना पर कुछ स्केचिंग की, जो कोड के बहुत व्यापक स्वाथ के निरंतर मूल्यांकन को सक्षम कर सके। मूल रूप से सभी स्थिरांक को MIR में कम करना और इसकी व्याख्या करना (कुछ मामलों में,
अमूर्त व्याख्या, यदि जेनेरिक हैं तो आप अभी तक मूल्यांकन नहीं कर सकते हैं, जहां चीजें मेरे लिए सबसे दिलचस्प होती हैं)।

हालांकि, ऐसा लगता है कि "बिलिन भाषा" के एक बहुत बड़े अंश का समर्थन करना काफी आसान होगा, व्यवहार में वास्तविक कोड स्मृति आवंटन को बहुत तेज़ी से करने की आवश्यकता के विरुद्ध हिट करता है। दूसरे शब्दों में, आप Vec या किसी अन्य कंटेनर का उपयोग करना चाहते हैं। और यहीं से यह पूरी व्याख्या योजना मेरे दिमाग में और अधिक जटिल होने लगती है।

उस ने कहा, @glaebhoerl , मुझे यह भी सुनना अच्छा लगेगा कि आप अपने पसंदीदा वैकल्पिक एंडगेम को स्पष्ट करते हैं। मुझे लगता है कि आपने const fn RFC में कुछ ऐसे विचारों को स्केच किया है, लेकिन मुझे लगता है कि इसे फिर से सुनना अच्छा होगा, और इस संदर्भ में। :)

आवंटन के साथ समस्या यह रन-टाइम में भाग रही है।
अगर हम किसी तरह उस कंपाइल-टाइम/रन-टाइम बैरियर को पार करने की अनुमति नहीं दे सकते हैं, तो मेरा मानना ​​है कि हमारे पास $#$ const fn $#$ के साथ काम करने वाला liballoc हो सकता है।
व्याख्या किए गए स्टैक पर बाइट-एड्रेसेबल मानों से निपटने के लिए उन प्रकार के आवंटन को प्रबंधित करना कठिन नहीं होगा।

वैकल्पिक रूप से, हम हर बार उस बाधा को पारित करने के लिए मूल्यों को आवंटित करने और भरने के लिए रनटाइम कोड उत्पन्न कर सकते हैं, हालांकि मुझे यकीन नहीं है कि किस प्रकार के उपयोगकेस हैं।

ध्यान रखें कि पूर्ण रूप से constexpr जैसे मूल्यांकन के साथ भी, const fn _अभी भी_ शुद्ध होगा: इसे 'static डेटा पर दो बार चलाने से ठीक वैसा ही परिणाम मिलेगा और नहीं दुष्प्रभाव।

@nikomatsakis अगर मेरे पास एक होता तो मैंने इसका उल्लेख किया होता। :) मैं मुख्य रूप से सिर्फ ज्ञात अज्ञात देखता हूं। जेनेरिक सिस्टम के हिस्से के रूप में const s के साथ पूरी चीज निश्चित रूप से सी ++ डिज़ाइन के रूप में समझी जाने वाली चीज़ों का हिस्सा थी। जहां तक const s और const जेनेरिक पैरामीटर जुड़े हुए हैं, यह देखते हुए कि हमारे पास पहले से ही const s के साथ उनके प्रकार के हिस्से के रूप में निश्चित आकार के सरणी हैं और हम अधिक सार करना चाहते हैं उन्हें, मुझे आश्चर्य होगा अगर वहाँ एक बहुत बेहतर था - जैसा कि केवल अधिक सामान्य के विपरीत - इसे करने का तरीका। const fn चीजों का हिस्सा अधिक वियोज्य और परिवर्तनशील लगता है। चीजों को और आगे ले जाने की कल्पना करना आसान है और const impl s और const Trait जैसी चीजें जेनरिक में हैं, लेकिन मैं _sure_ हूं इस तरह की सामान्य चीज़ के लिए पूर्व कला है जो पहले से ही चीजों का पता लगा चुकी है और हमें इसे खोजने का प्रयास करना चाहिए।

रस्ट भाषा के लिए मुख्य उपयोग के मामलों में, जिन्हें मुख्य रूप से निम्न-स्तरीय नियंत्रण की आवश्यकता होती है, जैसे कि गुठली, पहले से ही यथोचित रूप से अच्छी तरह से परोसी जाती है, लेकिन एक अन्य क्षेत्र जहां रस्ट में बहुत अधिक संभावनाएं हो सकती हैं, वे चीजें हैं जिन्हें मुख्य रूप से उच्च प्रदर्शन की आवश्यकता होती है, और में मंचित गणना के लिए वह स्थान शक्तिशाली समर्थन (किसी रूप में) (जो const fn पहले से ही एक बहुत ही सीमित उदाहरण है) ऐसा लगता है कि यह एक गेम-चेंजर हो सकता है। (बस पिछले कुछ हफ्तों में मुझे उन लोगों के दो अलग-अलग ट्वीट मिले, जिन्होंने बेहतर स्टेजिंग क्षमताओं वाली भाषा में रस्ट से स्विच करने का फैसला किया।) मुझे यकीन नहीं है कि भाषाओं में कोई भी मौजूदा समाधान "हमारे करीब" है - C++ का constexpr , D का तदर्थ CTFE, हमारे प्रक्रियात्मक मैक्रोज़ -- वास्तव में इस तरह की चीज़ों के लिए पर्याप्त प्रेरक और शक्तिशाली/पूर्ण महसूस करते हैं। (प्रक्रियात्मक मैक्रोज़ एक अच्छी चीज़ की तरह प्रतीत होते हैं, लेकिन एब्स्ट्रैक्शन और डीएसएल के लिए अधिक, प्रदर्शन-उन्मुख कोड पीढ़ी के लिए उतना नहीं।)

जहां तक ​​_क्या_प्रेरणादायक और पर्याप्त अच्छा होगा... मैंने इसे अभी तक नहीं देखा है, और मैं पूरी जगह से परिचित नहीं हूं, ठीक-ठीक, कहां देखना है। बेशक, उपरोक्त के अनुसार, हम कम से कम जूलिया और टेरा को देखना चाहेंगे, भले ही वे कई मायनों में रस्ट से काफी अलग भाषा की तरह लगें। मुझे पता है कि ओलेग किसलीव ने इस क्षेत्र में बहुत सारे दिलचस्प काम किए हैं। स्काला के लिए लैंसेट और लाइटवेट मॉड्यूलर स्टेजिंग पर Tiark Rompf का काम निश्चित रूप से देखने लायक लगता है। मुझे याद है कि किसी बिंदु पर @kmcallister द्वारा एक प्रेजेंटेशन देखकर निर्भर रूप से टाइप किया गया जंग कैसा दिख सकता है (जो कम से कम const हर जगह चिपके रहने से अधिक सामान्य हो सकता है), और मुझे ओलेग से प्रभाव में कुछ देखने की भी याद आती है वह प्रकार स्वयं स्टेजिंग का एक रूप है (जो संकलन- और रनटाइम के बीच चरण पृथक्करण पर विचार करना स्वाभाविक लगता है, चरणों की तरह है) ... कई अलग-अलग दिशाओं में बहुत सारे रोमांचक संभावित कनेक्शन, यही कारण है कि यह एक चूक जैसा महसूस होगा अवसर अगर हम केवल पहले समाधान के लिए प्रतिबद्ध थे जो हमारे साथ होता है। :)

(यह सिर्फ एक ब्रेनडंप था और मैंने लगभग निश्चित रूप से कई चीजों को अपूर्ण रूप से चित्रित किया है।)

हालांकि, ऐसा लगता है कि "बिलिन भाषा" के एक बहुत बड़े अंश का समर्थन करना काफी आसान होगा, व्यवहार में वास्तविक कोड स्मृति आवंटन को बहुत तेज़ी से करने की आवश्यकता के विरुद्ध हिट करता है। दूसरे शब्दों में, आप Vec या किसी अन्य कंटेनर का उपयोग करना चाहते हैं। और यहीं से यह पूरी व्याख्या योजना मेरे दिमाग में और अधिक जटिल होने लगती है।

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

इससे अधिक करने में सक्षम होना _nice_ होगा लेकिन संकलक-लागू इनवेरिएंट के साथ गैर-तुच्छ प्रकार के स्थिर उदाहरण बनाने में सक्षम होना आवश्यक है। सी ++ constexpr दृष्टिकोण बेहद सीमित है, लेकिन यह मेरे उपयोग के मामलों के लिए मुझे जो चाहिए उससे अधिक है: मुझे एक ऐसा फ़ंक्शन प्रदान करने की आवश्यकता है जो T पैरामीटर के साथ x प्रकार का उदाहरण बना सके y , और z जैसे कि फ़ंक्शन गारंटी देता है कि x , y , और z मान्य हैं (उदाहरण के लिए, x < y && z > 0 ), जैसे कि स्टार्टअप पर चलने वाले इनिशियलाइज़ेशन कोड के उपयोग के बिना परिणाम static वैरिएबल हो सकता है।

@briansmith FWIW एक और दृष्टिकोण जिसमें समान उपयोग के मामलों को हल करने का मौका है, यदि मैक्रोज़ में गोपनीयता स्वच्छता होगी, जो मुझे विश्वास है (उम्मीद है) हम उन्हें बनाने की योजना बना रहे हैं।

@briansmith FWIW एक और दृष्टिकोण जिसमें समान उपयोग के मामलों को हल करने का मौका है, यदि मैक्रोज़ में गोपनीयता स्वच्छता होगी, जो मुझे विश्वास है (उम्मीद है) हम उन्हें बनाने की योजना बना रहे हैं।

मुझे लगता है कि यदि आप प्रक्रियात्मक मैक्रोज़ का उपयोग करते हैं तो आप संकलन-समय पर x < y && z > 0 का मूल्यांकन कर सकते हैं। लेकिन, ऐसा लगता है कि स्थिर जंग में प्रक्रियात्मक मैक्रोज़ का उपयोग करने से कई महीने पहले, यदि वे कभी भी हों, तो ऐसा लगता है। const fn दिलचस्प है क्योंकि इसे स्थिर जंग _now_ के लिए सक्षम किया जा सकता है, जहां तक ​​​​मैं चीजों की स्थिति को समझता हूं।

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

@glaebhoerl https://anydsl.github.io/ भी है, जो यहां तक ​​​​कि उपयोग करता है
जंग की तरह वाक्यविन्यास;) वे मूल रूप से चरणबद्ध गणना को लक्षित कर रहे हैं और in
विशेष आंशिक मूल्यांकन।

शनिवार, 16 जनवरी, 2016 को शाम 6:29 बजे, एडुआर्ड-मिहाई बर्टेस्कु <
सूचनाएं@github.com> ने लिखा:

@glaebhoerl https://github.com/glaebhoerl मैं इसके लिए अपनी सांस नहीं रोकूंगा
सख्त स्वच्छता, यह बहुत संभव है कि हमारे पास एक बचने का तंत्र होगा
(बिल्कुल असली एलआईएसपी की तरह), इसलिए आप इसे किसी भी तरह की सुरक्षा के लिए नहीं चाहते हैं
उद्देश्य।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/rust-lang/rust/issues/24111#issuecomment -172271960।

29525 स्थिरीकरण से पहले तय किया जाना चाहिए

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

बस एक विचार: यदि हम कभी औपचारिक रूप से रस्ट के मेमोरी मॉडल को परिभाषित करते हैं, तो unsafe कोड को संभावित रूप से सुरक्षित और समझदारी से संकलित समय पर अमूर्त/प्रतीकात्मक रूप से व्याख्या करके मूल्यांकन किया जा सकता है - यानी कच्चे पॉइंटर्स का उपयोग होगा' t रनटाइम पर सीधे मेमोरी एक्सेस में बदल जाता है, बल्कि कुछ (उदाहरण के लिए उदाहरण के रूप में) आवंटित पते के हैशमैप में लुकअप की तरह, उनके प्रकार और मूल्यों के साथ, या इसी तरह, वैधता के लिए प्रत्येक चरण की जांच के साथ - इसलिए कि कोई भी निष्पादन जिसका व्यवहार अपरिभाषित है, rustc में सुरक्षा भेद्यता के बजाय _सख्ती से एक कंपाइलर-रिपोर्ट की गई त्रुटि होगी। (यह isize और usize को प्रतीकात्मक रूप से या प्लेटफॉर्म-निर्भर तरीके से संकलित समय पर संभालने की स्थिति से भी जुड़ा हो सकता है।)

मुझे यकीन नहीं है कि यह हमें const fn के संबंध में कहां छोड़ता है। एक ओर, यह संभवतः संकलन समय पर उपलब्ध होने के लिए और अधिक उपयोगी कोड खोलेगा - Box , Vec , Rc , unsafe का उपयोग कर कुछ भी प्रदर्शन अनुकूलन के लिए const fn हो सकता है" की सीमा अब अनिवार्य रूप से बाहर की ओर _ऐनिथिंग में स्थानांतरित कर दी जाएगी जिसमें FFI_ शामिल नहीं है। तो क्या हम _actually_ टाइप सिस्टम में const नेस की आड़ में ट्रैकिंग करेंगे, यह है कि कौन सी चीजें (सकर्मक रूप से) एफएफआई पर निर्भर करती हैं और कौन सी चीजें नहीं। और एफएफआई का उपयोग करता है या नहीं, कुछ ऐसा है जिसे लोग आंतरिक कार्यान्वयन विवरण के रूप में सही मानते हैं, और यह प्रतिबंध ( unsafe के विपरीत) _really_ उठाना संभव नहीं लगता है। और इस परिदृश्य के तहत शायद आपके पास fn s के लिए पात्र होने वाले const से कहीं अधिक होंगे जो नहीं करेंगे।

तो आपके पास अभी भी const ness एक मनमाना, कार्यान्वयन-उजागर प्रतिबंध के इर्द-गिर्द घूमता रहेगा, और आपको लगभग हर जगह const लिखना होगा। यह बहुत आकर्षक भी नहीं लगता...

यानी, कच्चे पॉइंटर्स का उपयोग रनटाइम पर सीधे मेमोरी एक्सेस में नहीं बदलेगा, बल्कि कुछ ... आवंटित पते के हैशमैप में लुकअप की तरह,

@glaebhoerl ठीक है, यह वह मॉडल है जिसका मैंने वर्णन किया है और जो @tsion की मिरी लागू कर रहा है।

मुझे लगता है कि शुद्धता के कारण एफएफआई भेद बहुत महत्वपूर्ण है, जो कि सुसंगतता के लिए _required_ है।
आप Rust const fn s के लिए GHC का उपयोग _नहीं कर सकते क्योंकि इसमें unsafePerformIO है।

मुझे स्वयं const कीवर्ड बहुत अधिक पसंद नहीं है, इसलिए मैं const fn foo<T: const Trait> ( const impl Trait for T की आवश्यकता के लिए) के बजाय const fn foo<T: Trait> के साथ ठीक हूं।

Sized की तरह, हमारे पास शायद गलत डिफ़ॉल्ट हैं, लेकिन मैंने ऐसा कोई अन्य प्रस्ताव नहीं देखा है जो वास्तविक रूप से काम कर सके।

@eddyb मुझे लगता है कि आप https://internals.rust-lang.org/t/mir-constant-evaluation/3143/31 से लिंक करना चाहते थे (टिप्पणी 31, 11 नहीं)।

@tsion फिक्स्ड, धन्यवाद!

अगर मैं पूरी तरह से ऑफ पॉइंट हूं तो कृपया इसे अनदेखा करें।

इस आरएफसी के साथ मैं जो समस्या देखता हूं वह यह है कि एक उपयोगकर्ता के रूप में, आपको जितना संभव हो उतने फ़ंक्शन const fn को चिह्नित करना होगा क्योंकि यह शायद सबसे अच्छा अभ्यास होगा। वही बात वर्तमान में सी ++ में कॉन्टेक्सप्र के साथ हो रही है। मुझे लगता है कि यह सिर्फ अनावश्यक वाचालता है।

डी में const fn नहीं है लेकिन यह किसी भी फ़ंक्शन को संकलन समय (कुछ अपवादों के साथ) पर कॉल करने की अनुमति देता है।

उदाहरण के लिए

// Standalone example.
struct Point { x: i32, y: i32 }

impl Point {
    fn new(x: i32, y: i32) -> Point {
        Point { x: x, y: y }
    }

    fn add(self, other: Point) -> Point {
        Point::new(self.x + other.x, self.y + other.y)
    }
}

const ORIGIN: Point = Point::new(0, 0); // works because 0, 0 are both known at compile time 
const ORIGIN2: Point = Point::new(0, 0); // ditto

const ANOTHER: Point = ORIGIN.add(ORIGIN2); // works because ORIGIN and ORIGIN2 are both const.
{
    let x: i32 = 42;
    let y: i32 = 24;
    const SOME_POINT: Point = Point::new(x, y); // Error: x and y are not known at compile time
}
{
    const x: i32 = 42;
    const y: i32 = 24;
    const SOME_POINT: Point = Point::new(x, y); // Works x and y are both known at compile time.
}

ध्यान दें, मैं वास्तव में एक जंग उपयोगकर्ता नहीं हूं और मैंने कुछ मिनट पहले ही आरएफसी पढ़ा है, इसलिए यह संभव है कि मैंने कुछ गलत समझा हो।

@MaikKlein RFC चर्चा में CTFE पर बहुत चर्चा हुई

मुझे यहां अवरोधकों की व्याख्या करने वाली कोई हालिया टिप्पणी नहीं दिख रही है, और ऑप बहुत रोशन नहीं कर रहा है। क्या स्थिति है। हम इसे फिनिश लाइन के पार कैसे ले जा सकते हैं?

इसका उपयोग रॉकेट द्वारा किया जाता है: https://github.com/SergioBenitez/Rocket/issues/19#issuecomment -269052006

देखें https://github.com/rust-lang/rust/issues/29646#issuecomment -271759986। इसके अलावा हमें खोजकर्ता पर अपनी स्थिति पर पुनर्विचार करने की आवश्यकता है क्योंकि मिरी ने "वैश्विक दुष्प्रभावों" की सीमा को आगे बढ़ाया है ( @solson और @nikomatsakis आईआरसी पर इस बारे में बात कर रहे थे)।

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

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

मैं लिंट के बारे में सहमत हूं। यह मौजूदा बिल्ट-इन लिंट के समान है missing_docs , missing_debug_implementations , और missing_copy_implementations ।

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

मुझे लगता है कि उन मामलों में #[allow(missing_const)] fn foo() {} काम कर सकता है?

@eddyb @nikomatsakis मेरा " const को हटाना एक ब्रेकिंग चेंज है" बिंदु बताता है कि हम आखिरकार कीवर्ड रखना चाहेंगे, क्योंकि यह डाउनस्ट्रीम का वादा है कि fn _remain_ const होगा

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

जब तक कि यह केवल सार्वजनिक-सामना करने वाली वस्तुओं पर आवश्यक न हो, और यह एक भ्रमित नियम की तरह लगता है।

मुझे यह पसंद है... मुझे नहीं लगता कि यह भ्रमित करने वाला होगा। आपका सार्वजनिक इंटरफ़ेस सुरक्षित है क्योंकि आप const fn द्वारा बुलाए गए फ़ंक्शन को नॉट-कॉन्स्ट नहीं बना सकते हैं

तकनीकी रूप से कार्यों को notconst के रूप में एनोटेट करना बेहतर होगा, क्योंकि मुझे उम्मीद है कि अन्य तरीकों की तुलना में const fn अधिक होगा।

notconst भी रस्ट के डिजाइन दर्शन के अनुरूप होगा। (यानी " mut , न कि const ")

जब तक कि यह केवल सार्वजनिक-सामना करने वाली वस्तुओं पर आवश्यक न हो, और यह एक भ्रमित नियम की तरह लगता है।

मुझे यह पसंद है... मुझे नहीं लगता कि यह भ्रमित करने वाला होगा।

मैं इस विचार पर फ़्लॉप कर रहा हूँ। इसके लाभ हैं (सार्वजनिक इंटरफ़ेस निर्णय लेते समय केवल const fn के बारे में सोचें) लेकिन मैंने एक और तरीके से सोचा कि यह भ्रमित हो सकता है:

आपका सार्वजनिक इंटरफ़ेस सुरक्षित है क्योंकि आप const fn द्वारा बुलाए गए फ़ंक्शन को नॉट-कॉन्स्ट नहीं बना सकते हैं

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

मुझे उम्मीद है कि अन्य तरीकों की तुलना में कहीं अधिक const fn होगा।

मैंने थोड़ी देर के लिए इस तरह सोचा, लेकिन यह केवल शुद्ध जंग पुस्तकालय के बक्से के लिए सच होगा। एफएफआई-आधारित एफएनएस कास्ट बनाना संभव नहीं होगा (भले ही वे केवल ट्रांजिटिव एफएफआई-आधारित हों, जो कि बहुत सारी चीजें हैं), इसलिए const fn की सरासर राशि उतनी खराब नहीं हो सकती है जैसा कि आपने और मैंने सोचा था।

मेरा वर्तमान निष्कर्ष: कोई भी गैर-स्पष्ट const fn समस्याग्रस्त लगता है। कीवर्ड को बहुत अधिक लिखने से बचने का कोई अच्छा तरीका नहीं हो सकता है।

साथ ही, रिकॉर्ड के लिए, notconst एक महत्वपूर्ण परिवर्तन होगा।

@solson एक बहुत अच्छा बिंदु।

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

मुझे ऐसा लगता है कि जब हमने पहली बार const fn को अपनाया तो इस ट्रेड-ऑफ पर काफी चर्चा हुई। मुझे लगता है कि @solson का विश्लेषण भी सही है। मुझे लगता है कि केवल एक चीज जो बदल गई है, वह यह है कि शायद कांस्टेबल fns का प्रतिशत बड़ा हो गया है, लेकिन मुझे नहीं लगता कि यहां मौलिक ट्रेडऑफ को बदलने के लिए पर्याप्त है। धीरे-धीरे अपने सार्वजनिक इंटरफेस आदि में const fn जोड़ना कष्टप्रद होगा, लेकिन ऐसा ही जीवन है।

@nikomatsakis मुझे जो परेशान कर रहा है वह इन दो तथ्यों का संयोजन है:

• हम समय से पहले सब कुछ नहीं देख सकते हैं, unsafe कोड "गतिशील रूप से गैर-स्थिरांक" हो सकता है
• हम जेनरिक और विशेषता के लिए जो कुछ भी करते हैं, वह "सही" और लचीलेपन के बीच एक ट्रेडऑफ़ होने जा रहा है

यह देखते हुए कि "वैश्विक दुष्प्रभाव" मुख्य चीज है जो कोड को होने से रोकता है const fn , क्या यह "प्रभाव प्रणाली" नहीं है जो रस्ट के पास हुआ करता था और हटा दिया गया था?
क्या हमें "प्रभाव स्थिरता" के बारे में बात नहीं करनी चाहिए? कोड के समान लगता है कि कुछ पुस्तकालय आईएमओ को कभी नहीं घबराते हैं।

@eddyb बिल्कुल const एक प्रभाव प्रणाली है और हाँ यह सभी डाउनसाइड्स के साथ आता है जिससे हम जितना संभव हो सके उनसे बचना चाहते हैं ... यह प्रशंसनीय है कि अगर हम जोड़ने के दर्द को सहन करने जा रहे हैं एक प्रभाव प्रणाली में, हम कुछ सिंटैक्स पर विचार करना चाह सकते हैं जिसे हम अन्य प्रकार के प्रभावों के लिए स्केल कर सकते हैं। उदाहरण के तौर पर, हम unsafe (एक प्रभाव भी) के साथ एक समान कीमत चुका रहे हैं, हालांकि मुझे यकीन नहीं है कि उनको एकीकृत करने के बारे में सोचना समझ में आता है।

तथ्य यह है कि उल्लंघन गतिशील रूप से हो सकते हैं, ऐसा लगता है कि यह ऑप्ट-इन करने के लिए और भी अधिक कारण है, नहीं?

इस बारे में कैसा है:

सामान्य तौर पर, मुझे लगता है, const fn s का उपयोग केवल निर्माणकर्ताओं के लिए किया जाना चाहिए ( new ) या जहां बिल्कुल आवश्यक हो।

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

@torkleyy आप पहले से ही ऐसे सहायकों के साथ ऐसा कर सकते हैं जिन्हें निर्यात नहीं किया जाता है।

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

IRC पर @eddyb ने इस फीचर गेट को विभाजित करने का प्रस्ताव रखा ताकि हम उनकी घोषणा और निकायों के विवरण का पता लगाने से पहले कॉन्स्ट fns को कॉल को स्थिर कर सकें। क्या यह एक अच्छे विचार की तरह लगता है?

@durka यह मेरे लिए बहुत अच्छा लगता है, एक जंग उपयोगकर्ता के रूप में जो कंपाइलर इंटर्नल के बारे में ज्यादा नहीं जानता है।

यहां मेरी समझ की कमी के लिए क्षमा करें, लेकिन घोषणा को स्थिर किए बिना कॉल को const फ़ंक्शन में स्थिर करने का क्या अर्थ है।

क्या हम कह रहे हैं कि संकलक किसी तरह यह जान लेगा कि कुछ माध्यमों से क्या है और क्या स्थिर नहीं है, लेकिन उस हिस्से को कुछ समय के लिए चर्चा/कार्यान्वयन के लिए खुला छोड़ दें?

फिर कॉल को स्थिर कैसे किया जा सकता है यदि संकलक बाद में अपना मन बदल सकता है जो स्थिर है?

@nixpulvis कुछ const fn पहले से ही मानक पुस्तकालय में मौजूद हैं, उदाहरण के लिए UnsafeCell::new । यह प्रस्ताव इस तरह के कार्यों को निरंतर संदर्भों में कॉल करने की अनुमति देगा, उदाहरण के लिए static आइटम का प्रारंभकर्ता।

@nixpulvis मेरा मतलब था const fn फ़ंक्शंस को अस्थिर-उपयोग कोड (जैसे मानक लाइब्रेरी) द्वारा परिभाषित किया गया था , निरंतर संदर्भों से, स्थिर रस्ट कोड में परिभाषित नियमित फ़ंक्शन नहीं ।

cc @rust-lang/lang https://github.com/rust-lang/rust/issues/24111#issuecomment -310245900 पर

जबकि मैं सभी const fn s पहले कॉल को स्थिर करने के पक्ष में हूं, यदि यह तेजी से हो सकता है, तो यह मेरे लिए स्पष्ट नहीं है कि const fn सुविधा को स्थिर करने में क्या बाधा है। आज शेष चिंताएँ क्या हैं? उन्हें संबोधित करने का मार्ग क्या होगा?

@SimonSapin यह अधिक है कि हम आज const fn s घोषित करने के लिए डिज़ाइन को स्पष्ट नहीं कर रहे हैं और न ही हम उनके और लक्षणों के बीच बातचीत पर सुनिश्चित हैं और कितना लचीलापन होना चाहिए।

मुझे लगता है कि मैं कॉन्स्ट एफएन के उपयोग को स्थिर करने के इच्छुक हूं। यह एक एर्गोनोमिक और अभिव्यक्ति की जीत की तरह लगता है और मैं अभी भी "सामान्य कोड लिखने" में सक्षम होने की तुलना में संकलन-समय निरंतर मूल्यांकन को संभालने के बेहतर तरीके की कल्पना नहीं कर सकता।

कॉन्स्ट fn के उपयोग को स्थिर करें।

यह मानक पुस्तकालय में कुछ कार्यों को const के रूप में स्थिर करता है, पुस्तकालय टीम को कम से कम कुछ ऑडिट करना चाहिए।

मैंने इनवोकेशन को स्थिर करने के लिए एक पीआर https://github.com/rust-lang/rust/issues/43017 सबमिट किया है, साथ ही प्रति @petrochenkov में ऑडिट किए जाने वाले कार्यों की सूची भी।

मेरे पास एक प्रश्न/टिप्पणी है कि इसका उपयोग कुछ विशेषता/निहित परिस्थितियों में कैसे किया जा सकता है। हाइपोथेटिक रूप से, मान लें कि हमारे पास Zero विशेषता वाला गणित पुस्तकालय है:

pub trait Zero {
    fn zero () -> Self;
}

इस विशेषता के लिए zero विधि की const होने की आवश्यकता नहीं है, क्योंकि यह इसे $ Vec द्वारा समर्थित कुछ BigInt प्रकार द्वारा निहित होने से रोकेगा। लेकिन मशीन स्केलर और अन्य सरल प्रकारों के लिए, यह कहीं अधिक व्यावहारिक होगा यदि विधि const ।

impl Zero for i32 {
    const fn zero () -> i32 { 0 } // const
}

impl Zero for BigInt {
    fn zero () -> BigInt { ... } // not const
}

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

आप अलग-अलग व्यवहार करने के लिए विशेषता के विभिन्न कार्यान्वयन क्यों चाहते हैं? आप इसे सामान्य संदर्भ में उपयोग नहीं कर सकते। आप बस एक कॉन्स fn के साथ स्केलर पर एक स्थानीय इम्प्लांट बना सकते हैं।

@Daggerbot यही एकमात्र तरीका है जिसे मैं लक्षणों में const fn के लिए आगे देखता हूं - विशेषता होने के लिए आवश्यक है कि सभी निहितार्थ const fn प्रभावी रूप से " const impl s" होने की तुलना में बहुत कम आम है। .

@jethrogb आप कर सकते हैं, हालांकि इसके लिए स्थिरता की आवश्यकता है कि यह इम्प्लांट की संपत्ति हो।
मेरे मन में यह है कि एक सामान्य const fn , उदाहरण के लिए T: Zero बाध्य, को $#$7$# के लिए impl की Zero T आवश्यकता होगी const fn विधियों को शामिल करने के लिए कहा जाता है, जब कॉल निरंतर संदर्भ से आता है (उदाहरण के लिए एक और const fn )।

यह सही नहीं है लेकिन कोई बेहतर विकल्प सामने नहीं रखा गया है - आईएमओ इसके सबसे करीब होगा "कॉल स्टैक से किसी भी कॉल और त्रुटि को गहराई से अनुमति दें यदि संकलन-समय पर कुछ भी संभव नहीं है", जो उतना बुरा नहीं है। पहली छाप में लग सकता है - इसके बारे में अधिकांश चिंता पश्चगामी संगतता के साथ है, यानी एक समारोह को चिह्नित करना const fn यह सुनिश्चित करता है कि तथ्य दर्ज किया गया है और संचालन को संकलन-समय पर मान्य नहीं करने के लिए इसे बनाने की आवश्यकता नहीं होगी const fn ।

क्या इससे मसला हल नहीं होगा?

pub trait Zero {
    fn zero() -> Self;
}

pub trait ConstZero: Zero {
    const fn zero() -> Self;
}

impl<T: ConstZero> Zero for T {
    fn zero() -> Self {
        <Self as ConstZero>::zero()
    }
}

मैक्रोज़ के साथ बॉयलरप्लेट को कम किया जा सकता है।

दो अलग-अलग लक्षण ( Zero और ConstZero ) होने की मामूली असुविधा के अलावा, जो लगभग एक ही काम करते हैं, मुझे कंबल कार्यान्वयन का उपयोग करते समय एक संभावित समस्या दिखाई देती है:

// Blanket impl
impl<T: ConstZero> Zero for T {
    fn zero () -> Self { T::const_zero() }
}

pub struct Vector2<T> {
    pub x: T,
    pub y: T,
}

impl<T: ConstZero> ConstZero for Vector2<T> {
    const fn const_zero () -> Vector2<T> {
        Vector2 { x: T::const_zero(), y: T::const_zero() }
    }
}

// Error: This now conflicts with the blanket impl above because Vector2<T> implements ConstZero and therefore Zero.
impl<T: Zero> Zero for Vector2<T> {
    fn zero () -> Vector2<T> {
        Vector2 { x: T::zero(), y: T::zero() }
    }
}

यदि हम ब्लैंकेट इम्प्लांट हटा देते हैं तो त्रुटि दूर हो जाएगी। कुल मिलाकर, यह एक कंपाइलर में लागू करने के लिए शायद सबसे आसान है क्योंकि यह भाषा में कम से कम जटिलता जोड़ता है।

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

impl<T: Zero> Zero for Vector2<T> {
    const fn zero () -> Vector2<T> {
        Vector2 { x: T::zero(), y: T::zero() }
    }
}

constexpr के साथ काम करते समय IIRC, C++ कुछ इस तरह की अनुमति देता है। यहां नकारात्मक पक्ष यह है कि यह const केवल तभी लागू होगा जब <T as Zero>::zero भी const हो। क्या यह एक त्रुटि होनी चाहिए, या क्या संकलक इस const को अनदेखा कर देता है जब यह लागू नहीं होता है (जैसे C++)?

इनमें से कोई भी उदाहरण समस्या का पूरी तरह से समाधान नहीं करता है, लेकिन मैं वास्तव में इससे बेहतर तरीके के बारे में नहीं सोच सकता।

संपादित करें: @andersk का सुझाव त्रुटियों के बिना पहला उदाहरण संभव बना देगा। जहां तक ​​​​कंपाइलर कार्यान्वयन जाता है, यह शायद सबसे अच्छा/सरल समाधान होगा।

@Daggerbot यह RFC 1210 (विशेषज्ञता) के अंत में प्रस्तावित "जाली" नियम के लिए उपयोग के मामले की तरह लगता है। अगर आप लिखते हैं

impl<T: ConstZero> Zero for T {…}  // 1
impl<T: ConstZero> ConstZero for Vector2<T> {…}  // 2
impl<T: Zero> Zero for Vector2<T> {…}  // 3
impl<T: ConstZero> Zero for Vector2<T> {…}  // 4

फिर हालांकि 1 3 के साथ ओवरलैप करता है, उनके चौराहे को 4 से ठीक से कवर किया जाता है, इसलिए इसे जाली नियम के तहत अनुमति दी जाएगी।

http://smallcultfollowing.com/babysteps/blog/2016/09/24/intersection-impls/ भी देखें।

यह एक अविश्वसनीय रूप से जटिल प्रणाली है, जिससे हम बचना चाहते हैं।

हाँ, जाली नियम की आवश्यकता होगी।

@eddyb आप क्या जटिल मानते हैं?

@Kixunil कुछ impl s को const fn के रूप में चिह्नित करने के बजाय, मानक पुस्तकालय में लगभग हर एक विशेषता को डुप्लिकेट कर रहा है।

हम यहां पटरी से उतर रहे हैं। वर्तमान में मुद्दा const fn के उपयोग को स्थिर करने का है। const fn विशेषता विधियों या const impl Trait for Foo को अनुमति देना एक दूसरे के लिए और स्वीकृत RFC के लिए ऑर्थोगोनल हैं।

@ oli-obk यह नया RFC नहीं है बल्कि const fn के लिए ट्रैकिंग समस्या है।

मैंने अभी देखा, और मेरी टिप्पणी संपादित की।

@eddyb हाँ, लेकिन यह संकलक के लिए आसान है (शून्य विशेषज्ञता, लेकिन हम शायद वैसे भी विशेषज्ञता चाहते हैं) और लोगों को ConstTrait से भी बाध्य करने की अनुमति देता है।

वैसे भी, मैं इम्प्लांट्स को कॉन्स्टेबल के रूप में चिह्नित करने का विरोध नहीं कर रहा हूं। मैं कंपाइलर ऑटो-जनरेटिंग ConstTrait: Trait की भी कल्पना कर रहा हूं।

@Kixunil यह बहुत आसान नहीं है, खासकर यदि आप इसे विशेषज्ञता के साथ कर सकते हैं।
कंपाइलर को ConstTrait: Trait जैसे कुछ भी ऑटो-जेनरेट करने की आवश्यकता नहीं होगी, न ही विशेषता प्रणाली को इनमें से किसी के बारे में जानने की आवश्यकता है, किसी को केवल कार्यान्वयन के माध्यम से रिकर्स करने की आवश्यकता है (या तो एक ठोस impl या एक where बाउंड) जो विशेषता प्रणाली उन्हें प्रदान करती है और उनकी जांच करती है।

मैं सोच रहा हूं कि क्या const fns को UnsafeCell तक पहुंच की अनुमति नहीं देनी चाहिए। वास्तव में स्थिरांक व्यवहार की अनुमति देना आवश्यक है:

const fn dont_change_anything(&self) -> bool {
    let old = self.cell.get();
    self.cell.set(!old);
    old
}

अब तक मैंने देखा है कि set const नहीं है। सवाल यह है कि क्या यह हमेशा के लिए रहेगा। दूसरे शब्दों में: क्या unsafe कोड इस बात पर भरोसा कर सकता है कि अपरिवर्तनीय डेटा पर समान const फ़ंक्शन चलाते समय हमेशा वही परिणाम आज और भाषा/लाइब्रेरी के प्रत्येक भावी रिलीज़ में वापस आ जाएगा?

const fn का मतलब अपरिवर्तनीय नहीं है, इसका मतलब है कि संकलन-समय पर कहा जा सकता है।

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

@Kixunil आप चाहते हैं https://github.com/rust-lang/rfcs/issues/1631

@jethrogb लिंक के लिए धन्यवाद!

मैंने देखा कि mem::size_of const fn के रूप में लागू किया जाता है। क्या यह mem::transmute और अन्य के लिए संभव होगा? जंग इंट्रिनिक्स कंपाइलर के लिए आंतरिक रूप से संचालित होता है, और मैं इसे अनुमति देने के लिए उचित परिवर्तन करने के लिए पर्याप्त परिचित नहीं हूं। अन्यथा, मुझे इसे लागू करने में खुशी होगी।

दुर्भाग्य से मूल्यों पर काम करना जादुई रूप से कुछ बनाने की तुलना में थोड़ा कठिन है। transmute को मिरी की आवश्यकता है। मिरी को कंपाइलर में लाने की दिशा में एक पहला कदम पहले से ही चल रहा है: #43628

इसलिए! *Cell::new , mem::{size,align}_of , ptr::null{,_mut} , Atomic*::new , Once::new और {integer}::{min,max}_value को स्थिर करने में कोई रुचि? क्या हमारे पास यहाँ fcps होगा या व्यक्तिगत ट्रैकिंग समस्याएँ पैदा होंगी?

हां।

मैं किसी भी टीम का हिस्सा नहीं हूं जिसके पास इस पर निर्णय लेने की शक्ति है, लेकिन मेरी व्यक्तिगत राय यह है कि mem::{size,align}_of को छोड़कर ये सभी इतने छोटे हैं कि रबर-स्टैम्प की गति के बिना उन्हें अब स्थिर किया जा सकता है एफ.सी.पी.

एक उपयोगकर्ता के रूप में मैं जितनी जल्दी हो सके कॉन्स्ट एक्सप्रेशन में mem::{size,align}_of का उपयोग करना चाहता हूं, लेकिन मैंने @nikomatsakis को उनके इंस्टा-कॉन्स्टेबल होने के बारे में चिंता व्यक्त की है जब उन्हें const fn s बनाया गया था . मुझे नहीं पता कि क्या विशिष्ट चिंताएँ हैं या केवल सामान्य सावधानी है, लेकिन IIRC यही कारण है कि प्रति-फ़ंक्शन फ़ीचर गेट जोड़े गए। मुझे लगता है कि इन दोनों के लिए चिंता का विषय काफी समान होगा कि वे एक साझा कर सकते हैं FCP. मुझे नहीं पता कि क्या @rustbot एक ही GitHub थ्रेड में अलग-अलग fcps को हैंडल कर सकता है, इसलिए शायद अलग-अलग मुद्दों को खोलना बेहतर है।

@durka क्या आप उन सभी कार्यों की स्थिरता को स्थिर करने के लिए एक ट्रैकिंग समस्या खोल सकते हैं? मैं प्रस्ताव दूंगा FCP एक बार यह हो गया।

@aturon https://github.com/rust-lang/rust/issues/46038

आवंटन :: लेआउट पर कॉन्स्ट एफएनएस के बारे में चर्चा में एक लीड का पालन करने के लिए:
क्या const fn में घबराहट की अनुमति दी जा सकती है और इसे संकलन त्रुटि के रूप में माना जा सकता है? यह वही है जो अब निरंतर अंकगणितीय अभिव्यक्तियों के साथ किया जाता है, है ना?

हाँ, मिरी के विलय के बाद यह एक सुपर तुच्छ विशेषता है

क्या यह अतिरिक्त std फ़ंक्शंस बनने का अनुरोध करने का सही स्थान है const ? यदि ऐसा है, तो Duration:: { new , from_secs , from_millis } सभी को const बनाने के लिए सुरक्षित होना चाहिए।

@remexre ऐसा करने का सबसे आसान तरीका शायद पीआर बनाना है और वहां libs टीम समीक्षा के लिए पूछना है।

https://github.com/rust-lang/rust/pull/47300 के रूप में PR'd। जब मैं उस पर था तब मैंने अस्थिर निर्माणकर्ताओं को const भी जोड़ा।

std फ़ंक्शंस को const घोषित करने की अनुमति देने पर कोई विचार? विशेष रूप से, mem::uninitialized और mem::zeroed ? मेरा मानना ​​है कि ये दोनों अतिरिक्त const कार्यों के लिए उपयुक्त उम्मीदवार हैं। एकमात्र कमी जो मैं सोच सकता हूं वह mem::uninitialized की एक ही कमी है, जहां Drop को लागू करने वाले structs का निर्माण $ ptr::write के बिना बनाया और लिखा जाता है।

अगर यह उपयुक्त लगे तो मैं एक पीआर भी संलग्न कर सकता हूं।

उसके लिए प्रेरणा क्या है? यह अमान्य बिट पैटर्न बनाने की अनुमति देने के लिए एक बेकार फुटगन की तरह लगता है जिसे तब अधिलेखित नहीं किया जा सकता है (क्योंकि वे एक कॉन्स्ट में हैं), लेकिन शायद मैं स्पष्ट दिख रहा हूं।

mem::uninitialized पूरी तरह से एक फ़ुटगन है, जो आपके हाथों से भी गोली मारती है यदि गलत तरीके से निशाना लगाया जाए। गंभीरता से, मैं यह नहीं बता सकता कि unsafe के रूप में चिह्नित होने के बावजूद, इस फ़ंक्शन का उपयोग कितना खतरनाक हो सकता है।

इन अतिरिक्त कार्यों को घोषित करने के पीछे प्रेरणा const इन कार्यों की प्रकृति से उपजी है, क्योंकि mem::uninitialized<Vec<u32>> को कॉल करने से हर बार एक ही परिणाम वापस आएगा, बिना किसी दुष्प्रभाव के। जाहिर है अगर अप्रारंभीकृत छोड़ दिया जाए, तो यह एक भयानक बात है। इसलिए, unsafe अभी भी मौजूद है।

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

use std::time::Instant;

pub struct GlobalTimer {
    time: UnsafeCell<Instant>
}

impl TimeManager {
    pub const fn init() -> TimeManager {
        TimeManager {
            time: UnsafeCell::new(Instant::now())
        }
    }
}

Instant::now() const फ़ंक्शन नहीं होने के कारण यह कोड संकलित नहीं होता है। Instant::now() को mem::uninitialized::<Instant>()) से बदलने से यह समस्या ठीक हो जाएगी यदि mem::uninitialized एक const fn होता। आदर्श रूप से, प्रोग्राम निष्पादन शुरू होने के बाद डेवलपर इस संरचना को प्रारंभ करेगा। और जबकि इस कोड को गैर-मुहावरेदार जंग माना जाता है (वैश्विक स्थिति आमतौर पर बहुत खराब होती है), यह कई मामलों में से एक है जहां वैश्विक स्थैतिक संरचनाएं उपयोगी होती हैं।

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

संपादित करें: const के फ़ंक्शन हस्ताक्षर में TimeManager::init() . भूल गए

हम्म, वह कोड संकलित करता है इसलिए मुझे अभी भी यहां सटीक प्रेरणा याद आ रही है ... यदि आप कोड लिख सकते हैं जैसे कि

const fn foo() -> Whatever {
    unsafe { 
        let mut it = mem::uninitialized();
        init_whatever(&mut it);
        it
    }
}

लेकिन const fns वर्तमान में इतने प्रतिबंधित हैं कि आप इसे लिख भी नहीं सकते...

मैं सैद्धांतिक औचित्य की सराहना करता हूं, लेकिन const pure के समान नहीं है और मुझे नहीं लगता कि हमें इन कार्यों के उपयोग को प्रोत्साहित करने के लिए कुछ भी करना चाहिए यदि यह कुछ सम्मोहक उपयोग के मामले के लिए आवश्यक नहीं है .

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

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

union s की सहायता से, पिछला कोड अब कंपाइल करता है । यह बिल्कुल भयानक है .

सभी अच्छे अंक भी। ये आंतरिक कार्य उपयोग-मामले की सूची में बहुत कम हैं, लेकिन वे अभी भी अंतिम const -ness के लिए उपयुक्त उम्मीदवार हैं।

यह भयानक रूप से आश्चर्यजनक है।

तो ... आप वास्तव में mem::uninitialized, as . को स्थिर करने की वकालत क्यों कर रहे हैं
विरोध करना, कहना, झटपट :: अभी? :)

गैर-स्थिरांक वाले structs के लिए निरंतर प्रारंभकर्ता होने की आवश्यकता है
आंतरिक सज्जा वास्तविक है (देखें: म्यूटेक्स)। लेकिन मुझे नहीं लगता कि यह मलर्की बना रहा है
इसे पाने का सही तरीका आसान है!

गुरु, 25 जनवरी, 2018 को दोपहर 2:21 बजे, स्टीफन फ्लेशमैन <
सूचनाएं@github.com> ने लिखा:

यूनियनों की मदद से, पिछला कोड अब संकलित होता है
https://play.rust-lang.org/?gist=be075cf12f63dee3b2e2b65a12a3c854&version=nightly ।
यह बिल्कुल भयानक है .

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/rust-lang/rust/issues/24111#issuecomment-360382201 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAC3n-HyWD6MUEbfHkUUXonh9ORGPSRoks5tOCtegaJpZM4D66IA
.

Instant::now स्थिरांक नहीं हो सकता। वह कार्य क्या लौटाएगा? संकलन का समय?

क्या कोई संक्षेप में बता सकता है कि इसे स्थिर करने के लिए क्या करने की आवश्यकता है? किस निर्णय पर पहुंचने की आवश्यकता है? क्या इसे बिल्कुल स्थिर करना है?

पैटर्न के साथ एकीकरण (जैसे https://gist.github.com/d0ff1de8b6fc15ef1bb6)

मैंने पहले ही सार पर टिप्पणी कर दी है, लेकिन यह देखते हुए कि const fn वर्तमान में एक पैटर्न में मिलान नहीं किया जा सकता है, यह स्थिरीकरण को अवरुद्ध नहीं करना चाहिए, है ना? हम इसे बाद में हमेशा अनुमति दे सकते हैं यदि यह समझ में आता है।

इंस्टेंट :: अब कॉन्स्टेबल नहीं हो सकता। वह कार्य क्या लौटाएगा? संकलन का समय?

लेकिन Instant::zero() या Instant::min_value() हो सकता है जो कि स्थिरांक है।

क्या कोई संक्षेप में बता सकता है कि इसे स्थिर करने के लिए क्या करने की आवश्यकता है? किस निर्णय पर पहुंचने की आवश्यकता है? क्या इसे बिल्कुल स्थिर करना है?

मुझे लगता है कि एकमात्र खुला प्रश्न यह है कि क्या हमारे कॉन्स्ट एफएन चेक इतने सख्त हैं कि गलती से किसी ऐसी चीज को अनुमति/स्थिर न करें जिसे हम कॉन्स्ट एफएन के अंदर नहीं चाहते हैं।

क्या हम रस्ट-लैंग/आरएफसीएस#2272 के माध्यम से पैटर्न के साथ एकीकरण कर सकते हैं? पैटर्न पहले से ही दर्दनाक हैं क्योंकि वे वर्तमान में हैं, आइए उन्हें और अधिक दर्दनाक न बनाएं।

मुझे लगता है कि एकमात्र खुला प्रश्न यह है कि क्या हमारे कॉन्स्ट एफएन चेक इतने सख्त हैं कि गलती से किसी ऐसी चीज को अनुमति/स्थिर न करें जिसे हम कॉन्स्ट एफएन के अंदर नहीं चाहते हैं।

अगर मैं गलत हूं तो मुझे सुधारें, लेकिन क्या वे चेक चेक के समान नहीं हैं जो वर्तमान में const प्रतिद्वंद्विता के शरीर में अनुमत हैं? मैं इस धारणा के तहत था कि const FOO: Type = { body }; और const FOO: Type = foo(); const fn foo() -> Type { body } समान हैं जो वे किसी भी मनमानी निकाय के लिए अनुमति देते हैं

@sgrif मुझे लगता है कि चिंता तर्कों के आसपास है, जो const fn है लेकिन const नहीं है।
साथ ही, यह भी स्पष्ट नहीं है कि लंबी अवधि में हम आज के const fn सिस्टम को बनाए रखना चाहते हैं।

क्या आप इसके बजाय कॉन्स्ट जेनेरिक (दोनों तरीकों) का सुझाव दे रहे हैं? (उदाहरण <const T> + const C<T> उर्फ const C<const T> ?)

मैं वास्तव में एक try_const! मैक्रो रखना चाहूंगा जो संकलन समय पर किसी भी अभिव्यक्ति का मूल्यांकन करने का प्रयास करेगा, और यदि संभव न हो तो घबराएं। यह मैक्रो नॉन-कॉन्स्ट fns (मिरी का उपयोग करके) को कॉल करने में सक्षम होगा, इसलिए हमें तब तक प्रतीक्षा करने की आवश्यकता नहीं है जब तक कि एसटीडी में प्रत्येक फ़ंक्शन को कॉन्स्ट एफएन के रूप में चिह्नित नहीं किया जाता है। हालाँकि, जैसा कि नाम से ही स्पष्ट है, यह किसी भी समय विफल हो सकता है, इसलिए यदि कोई फ़ंक्शन अपडेट किया गया है और अब इसे स्थिर नहीं किया जा सकता है, तो यह संकलन बंद कर देगा।

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

यदि फ़ंक्शन को पहले स्थान पर const fn चिह्नित किया गया था, तो क्रेट लेखक ने क्रेट को संकलित करने का प्रयास करते समय सीधे समस्या को देखा होगा और आप एनोटेशन पर भरोसा कर सकते हैं।

यदि केवल यह खेल के मैदान पर काम करता है... https://play.rust-lang.org/?gist=6c0a46ee8299e36202f959908e8189e6&version=stable

यह एक गैर पोर्टेबल (वास्तव में, इतना गैर पोर्टेबल है कि यह मेरे सिस्टम पर काम करता है लेकिन खेल के मैदान पर नहीं - फिर भी वे दोनों लिनक्स हैं) निर्मित कार्यक्रम में निर्माण समय शामिल करने का तरीका।

पोर्टेबल तरीका सिस्टमटाइम :: अब() को कॉन्स्ट मूल्यांकन में अनुमति देना होगा।

(यह किसी भी फ़ंक्शन/एक्सप्रेशन के कॉन्स्ट/संकलन-समय-eval के लिए एक तर्क है, भले ही यह const fn हो या नहीं।)

यह मुझे शामिल_बाइट्स में पूर्ण पथों को मना करने के तर्क की तरह लगता है

यदि आप सिस्टमटाइम :: अब कॉन्स्ट एफएन में अनुमति देते हैं, तो const FOO: [u8; SystemTime::now()] = [42; SystemTime::now()]; आपके सिस्टम परफ, शेड्यूलर और बृहस्पति की स्थिति के आधार पर यादृच्छिक रूप से त्रुटि होगी।

और भी बदतर:

const TIME: SystemTime = SystemTime::now();

इसका मतलब यह नहीं है कि TIME का मान सभी उपयोग साइटों पर समान है, विशेष रूप से वृद्धिशील और सभी क्रेटों वाले संकलनों में।

और यहां तक ​​​​कि पागलपन यह है कि आप foo.clone() को बहुत ही खराब तरीके से खराब कर सकते हैं, क्योंकि आप लंबाई 3 के साथ एक सरणी से क्लोन इंप का चयन कर सकते हैं लेकिन वापसी प्रकार लंबाई 4 की एक सरणी हो सकती है।

इसलिए भले ही हमने मनमाने कार्यों को कॉल करने की अनुमति दी हो, हम कभी भी SystemTime::new() को सफलतापूर्वक वापस आने की अनुमति नहीं देंगे, ठीक उसी तरह जैसे हम कभी भी वास्तविक यादृच्छिक संख्या जनरेटर की अनुमति नहीं देंगे।

@ SonyEx2 मुझे लगता है कि यह यहाँ थोड़ा हटकर है, लेकिन आप पहले से ही कुछ ऐसा लागू कर सकते हैं जो आज पहले से ही एक कार्गो build.rs फ़ाइल का उपयोग कर रहा है। कार्गो बुक में बिल्ड स्क्रिप्ट देखें, विशेष रूप से कोड जनरेशन के केस स्टडी पर अनुभाग।

@ ओली-ओबीके मुझे लगता है कि यह पूरी तरह से एक ही मुद्दा नहीं है क्योंकि एक एपीआई सुरक्षा के संस्करण के बारे में है जबकि दूसरा निर्माण पर्यावरण के बारे में है, हालांकि मैं मानता हूं कि देखभाल के साथ लागू नहीं होने पर वे दोनों पारिस्थितिक तंत्र के टूटने का कारण बन सकते हैं।

कृपया वर्तमान समय को const fn में प्राप्त करने की अनुमति न दें; हमें गैर-पुनरुत्पादित बनाने के लिए और अधिक/आसान तरीके जोड़ने की आवश्यकता नहीं है।

हम const fn में किसी भी प्रकार के गैर-नियतत्ववाद (जैसे यादृच्छिक संख्या, वर्तमान समय, आदि) की अनुमति नहीं दे सकते हैं - जिससे कि सिस्टम अस्वस्थता की ओर जाता है क्योंकि rustc मानता है कि निरंतर अभिव्यक्ति हमेशा दिए गए परिणाम का मूल्यांकन करती है एक ही इनपुट। थोड़ा और स्पष्टीकरण के लिए यहां देखें।

https://github.com/rust-lang/rust/issues/24111#issuecomment -376352844 जैसे मामलों को संभालने के लिए एक भविष्य की विधि एक साधारण प्रक्रियात्मक मैक्रो का उपयोग करना होगा जो वर्तमान समय प्राप्त करता है और इसे एक सादे संख्या के रूप में उत्सर्जित करता है या स्ट्रिंग टोकन। प्रक्रियात्मक मैक्रोज़ कमोबेश पूरी तरह से अप्रतिबंधित कोड हैं जो गैर-कॉन्स्ट रस्ट कोड का उपयोग करने वाले किसी भी सामान्य पोर्टेबल तरीके से समय प्राप्त कर सकते हैं।

@rfcbot fcp मर्ज

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

@ oli-obk की ओर से @rfcbot fcp मर्ज - स्थिरीकरण के बारे में सोचने और मुद्दों पर चर्चा करने लायक लगता है

टीम के सदस्य @nrc ने इसे मर्ज करने का प्रस्ताव दिया है। अगला चरण बाकी टैग की गई टीमों द्वारा समीक्षा है:

• [एक्स] @ एट्यूरॉन
• [एक्स] @ क्रैमर्टज
• [ ] @eddyb
• [x] @joshtriplett
• [ ] @nikomatsakis
• [एक्स] @ एनआरसी
• [ ] @pkfelix
• [x] @scottmcm
• [x] @ नावों के बिना

चिंताओं:

• डिज़ाइन (https://github.com/rust-lang/rust/issues/24111#issuecomment-376829588)
• समानांतर-कॉन्स्ट-लक्षणों का समाधान https://github.com/rust-lang/rust/issues/24111#issuecomment -377133537 द्वारा किया गया
• प्राथमिकता (https://github.com/rust-lang/rust/issues/24111#issuecomment-376652507)
• रनटाइम-पॉइंटर-एड्रेस (https://github.com/rust-lang/rust/issues/24111#issuecomment-386745312)

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

टैग की गई टीम के सदस्य मुझे क्या आदेश दे सकते हैं, इस बारे में जानकारी के लिए यह दस्तावेज़ देखें।

@rfcbot चिंता प्राथमिकता

हम संस्करण के बाद तक इस पर विचार करना चाह सकते हैं क्योंकि मुझे नहीं लगता कि हमारे पास किसी भी नतीजे से निपटने के लिए बैंडविड्थ है।

@rfcbot चिंता सब कुछ-const

हम एक सी ++ दुनिया में समाप्त हो जाते हैं जहां हर कार्य को करने के लिए प्रोत्साहन होता है जो आप const कर सकते हैं।

@ oli-obk के साथ संक्षिप्त चर्चा का सारांश:

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

2. हालांकि, आज const से छुटकारा पाना संभव नहीं है। आज की मिरी हर चीज की व्याख्या नहीं कर सकती है, और यह वास्तव में उत्पादन में पूरी तरह से परीक्षण नहीं किया गया है।

3. यह वास्तव में आज const की आवश्यकता के लिए पीछे की ओर संगत है, और फिर इस कीवर्ड को हटा दें और भविष्य में अनुमानित स्थिरता के लिए स्विच करें।

1, 2 और 3 को एक साथ रखना, भविष्य की रिलीज़ में निरंतर-मूल्यांकन योग्य कार्यों के सेट का विस्तार करने के बजाय, आज const कीवर्ड को स्थिर करना एक अच्छा विकल्प लगता है। कुछ समय बाद, हमारे पास एक पूरी तरह से युद्ध-परीक्षण किया गया हनी बेजर निरंतर मूल्यांकनकर्ता होगा, जो हर चीज का मूल्यांकन कर सकता है। उस समय, हम अनुमानित कॉन्स्ट पर स्विच कर सकते हैं।

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

मुझे जो बड़ा नुकसान दिख रहा है, वह यह है कि हम अनिवार्य रूप से const को क्रेट में उदारतापूर्वक स्प्रे करने की वकालत कर रहे हैं (अभी के लिए, भविष्य के विचारों के लिए @matklad की पोस्ट देखें)

@rfcbot चिंता समानांतर-कॉन्स्ट-लक्षण

ऐसा लगता है कि इसे स्थिर करने से तुरंत टोकरे का एक गुच्छा सामने में Const के साथ समानांतर विशेषता पदानुक्रम बना देगा: ConstDefault , ConstFrom , ConstInto , ConstClone , ConstTryFrom , ConstTryInto , आदि और ConstIndex और ऐसे के लिए पूछना। यह भयानक नहीं है - हमारे पास निश्चित रूप से आज Try के साथ थोड़ा सा है, हालांकि TryFrom को स्थिर करने से मदद मिलेगी - लेकिन मुझे लगता है कि कम से कम इसे बेहतर तरीके से हल करने के लिए योजना का एक स्केच होना अच्छा होगा। (क्या वह https://github.com/rust-lang/rfcs/pull/2237 है? मुझे नहीं पता)।

( @nrc : ऐसा लगता है कि बॉट ने केवल आपकी चिंताओं में से एक को पंजीकृत किया है)

समानांतर-कॉन्स्ट-लक्षणों का काल्पनिक भविष्य के कॉन्स्ट-ऑल-द-थिंग्स संस्करण में तुच्छ समाधान है। वे बस काम करेंगे।

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

स्पष्ट होने के लिए, ConstDefault बिना const fn के पहले से ही संभव है, और बाकी के उदाहरण ( ConstFrom , ConstInto , ConstClone , ConstTryFrom , ConstTryInto ) इस सुविधा के स्थिर होने के साथ भी संभव नहीं होगा, क्योंकि यह @oli-obk के रूप में उल्लेखित const विशेषता विधियों को नहीं जोड़ता है।

( ConstDefault एक संबद्ध कॉन्स्टेबल fn के बजाय संबंधित कॉन्स्ट का उपयोग करके संभव है, लेकिन जहां तक ​​​​मुझे पता है यह शक्ति के बराबर है।)

@scottmcm const fn विशेषता परिभाषाओं में आज संभव नहीं है (ओह @solson ने पहले ही इसका उल्लेख किया है)।

@eddyb यादृच्छिक विचार: क्या होगा यदि हमने विशेषता परिभाषाओं में const fn जोड़ने के बजाय const impl एक विशेषता को संभव बनाया है? (ये दोनों परस्पर अनन्य भी नहीं हैं।)

@whitequark https://github.com/rust-lang/rfcs/pull/2237 const impl के संयोजन के माध्यम से प्रत्येक fn const fn तक विस्तार करके उस विचार को शामिल करता है। impl , और सभी const विधियों के साथ impl की अनुमति देकर T: const Trait बाउंड को संतुष्ट करने के लिए, const में किसी भी तरीके को चिह्नित किए बिना विशेषता परिभाषा ही।

@rfcbot चिंता डिजाइन

हमने ऐतिहासिक रूप से कई कारणों से किसी एक विशिष्ट const fn प्रणाली को स्थिर करने पर ध्यान दिया है:

• वर्तमान वाला trait s का समर्थन नहीं करता है जिसके लिए const fn विधियों की आवश्यकता होती है, या विशेषता impl s जो const fn तरीके प्रदान करते हैं (देखें https://github. com/rust-lang/rfcs/pull/2237 ऐसा करने के कुछ तरीकों के लिए)
• संबंधित रूप से, अलग-अलग लक्षणों के बिना T: Trait बाध्य const fn के माध्यम से उपयोग की जाने वाली विधि के लिए पूछने की समस्या है, और अधिमानतः केवल जब संकलन-समय पर उपयोग किया जाता है (उदाहरण के लिए Option::map रनटाइम पर समान काम करेगा लेकिन सीटीएफई में कॉन्स्ट-कॉल करने योग्य बंद करने की आवश्यकता है)
• बहुत सारे एल्गोरिदम, संग्रह और अमूर्त संभावित रूप से मूल्यांकन योग्य होने के साथ, पूरे क्रेट हो सकते हैं जो हर जगह const fn का उपयोग करेंगे ( libcore दिमाग में आता है)

विभिन्न डिज़ाइन विकल्प हैं जो इन सभी समस्याओं में से अधिकांश को कम कर देंगे (दूसरों को पेश करने की कीमत पर), उदाहरण के लिए ये कुछ ऐसे हैं जो सामने आए हैं:

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

क्योंकि इस तरह आपका टोकरा किसी अन्य टोकरे में एक फ़ंक्शन के आधार पर समाप्त हो सकता है जो संकलन समय का मूल्यांकन करता है, और फिर टोकरा लेखक फ़ंक्शन हस्ताक्षर को प्रभावित नहीं करता है, लेकिन फ़ंक्शन को संकलन समय मूल्यांकन योग्य होने से रोकता है।

@leoschwarz क्या यह पहले से ही ऑटो लक्षणों की समस्या नहीं है? हो सकता है कि इसका समाधान इस तरह के अनपेक्षित टूट-फूट का पता लगाने के लिए रस्ट-सेवरवर को कार्गो के साथ एकीकृत करना है।

उस ने कहा, यह मेरे लिए स्पष्ट नहीं है कि क्या होता है यदि मिरी की मूल्यांकन समय सीमा है कि आप (लाइब्रेरी लेखक के रूप में) गलती से अधिक हो जाते हैं, जिससे संकलन विफलता डाउनस्ट्रीम हो जाती है।

@nrc मुझे लगता है कि "सब कुछ-कॉन्स्ट" सच है, लेकिन कोई मुद्दा नहीं है। हां, हम चीजों की एक बड़ी संख्या को चिह्नित करेंगे const ।

बस यह बताना चाहता हूं कि मुझे यकीन नहीं है कि मैं चाहता हूं कि सब कुछ अनुमानित हो
स्थिरांक यह इस बारे में निर्णय है कि रनटाइम या संकलन समय अधिक है
जरूरी। कभी-कभी मुझे लगता है कि संकलक पर्याप्त गणना करता है
संकलन समय!

बुध, मार्च 28, 2018 अपराह्न 2:49 बजे, जोश ट्रिपलेट नोटिफिकेशन @github.com
लिखा था:

@nrc https://github.com/nrc मुझे लगता है कि "सब कुछ-कॉन्स्ट" सच है, लेकिन नहीं
एक मुद्दा। हां, हम चीजों की एक बड़ी संख्या को चिह्नित करेंगे।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/rust-lang/rust/issues/24111#issuecomment-376914220 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAC3ny9Wm9JK6p-fXf6gbaEgjFtBpMctks5ti6LigaJpZM4D66IA
.

मूल्यांकन समय सीमा

वह सीमा जल्द ही समाप्त हो गई है।

बस यह बताना चाहता हूं कि मुझे यकीन नहीं है कि मैं चाहता हूं कि हर चीज का अनुमान लगाया जाए।

अरे नहीं, हम संकलन-समय पर बेतरतीब ढंग से चीजों की गणना नहीं करने जा रहे हैं। स्टैटिक्स, स्थिरांक, एनम वैरिएंट डिस्क्रिमिनेंट्स और सरणी लंबाई के शरीर में यादृच्छिक चीजों की गणना करने की अनुमति दें

@rfcbot ने समांतर-स्थिरांक-लक्षणों को हल किया

सुधार के लिए धन्यवाद दोस्तों!

वह सीमा जल्द ही समाप्त हो गई है।

बहुत बढ़िया। उस स्थिति में, ऑटो-कॉन्स्ट-एफएन (जंग-सेवर के कुछ एकीकरण के साथ या टूटने के बारे में जानकारी देने के समान) भयानक लगता है, हालांकि "लॉगिंग जोड़ें और टूटने का कारण" समस्याग्रस्त हो सकता है। यद्यपि आप संस्करण संख्या को टक्कर दे सकते हैं, मुझे लगता है कि ऐसा नहीं है कि वे सीमित हैं।

लॉगिंग और प्रिंटिंग स्थिरांक के मेरे मॉडल में "ठीक" दुष्प्रभाव हैं। यदि सभी सहमत हों तो हम इसका समाधान निकालने में सक्षम होंगे। हम फाइलों को भी लिख सकते थे (वास्तव में नहीं, लेकिन ऐसा कार्य करें जैसे हमने किया और सब कुछ फेंक दिया)।

मैं वास्तव में साइड इफेक्ट को चुपचाप दूर करने के बारे में चिंतित हूं।

हम चर्चा कर सकते हैं कि एक बार जब हम उनके चारों ओर एक आरएफसी बनाते हैं। अभी के लिए आपके पास स्थिरांक में "दुष्प्रभाव" नहीं हो सकते हैं। कॉन्स्ट fn . को स्थिर करने के लिए विषय ऑर्थोगोनल है

मैं अनुमान लगाने के लिए "बस एक सेवर चेतावनी" दृष्टिकोण के बारे में थोड़ा चिंतित हूं
स्थिरता यदि एक टोकरा लेखक जिसने कभी निरंतरता के बारे में नहीं सोचा, देखता है
"चेतावनी: आपके द्वारा अभी किया गया परिवर्तन foo() in . को कॉल करना असंभव बना देता है
कॉन्स्ट संदर्भ, जो पहले संभव था", क्या वे इसे केवल a . के रूप में देखेंगे
गैर अनुक्रमिक और इसे चुप? जाहिर है, इस मामले में लोग अक्सर सोचते हैं
जिसके बारे में कार्य स्थिर हो सकते हैं। और अच्छा होगा अगर ज्यादा से ज्यादा लोग करें
वह (एक बार const_fn स्थिर है)। लेकिन क्या आउट-ऑफ-द-ब्लू चेतावनियां सही हैं
इसे प्रोत्साहित करने का तरीका?

गुरु, 29 मार्च, 2018 को सुबह 4:36 बजे, ओलिवर श्नाइडर नोटिफिकेशन @github.com
लिखा था:

हम चर्चा कर सकते हैं कि एक बार जब हम उनके चारों ओर एक आरएफसी बनाते हैं। अभी के लिए आप
स्थिरांक में "दुष्प्रभाव" नहीं हो सकते। विषय ओर्थोगोनल है
स्थिरांक fn

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/rust-lang/rust/issues/24111#issuecomment-377164275 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAC3n3MtmvrDF42Iy0nhZ2q8xC-QGcvXks5tjJ0ggaJpZM4D66IA
.

मुझे लगता है कि स्पष्ट const fn कई एपीआई को परेशान और अव्यवस्थित कर सकता है, हालांकि मुझे लगता है कि निहित रूप से मानने के विकल्प में व्यावहारिक होने के लिए बहुत से मुद्दे हैं:

• साइड इफेक्ट्स को फेंकने से कोड अलग तरह से व्यवहार कर सकता है (लिखें और फिर फ़ाइल पढ़ें) अगर इसे कॉन्स्ट या गैर कॉन्स्ट कहा जाता है।
• बाहरी कार्यों को कॉल करने का मतलब है कि हमेशा दुष्प्रभाव हो सकते हैं, इसलिए असुरक्षित कोड शायद कभी भी अनुमान नहीं लगाया जा सकता है।
• जेनेरिक कोड के लिए कॉन्स्ट एफएन का अनुमान कब लगाया जा सकता है? क्या यह मोनोमोर्फिज़ेशन समय पर किया जाएगा?

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

हो सकता है कि इस तरह की सुविधा को क्रेट लेवल कॉन्फिगर फ्लैग के रूप में लागू किया जा सकता है जिसे क्रेट की जड़ में जोड़ा जा सकता है, #![infer_const_fn] या ऐसा कुछ, और हमेशा के लिए ऑप्ट-इन रहें। यदि ध्वज जोड़ा जाता है, तो टोकरा में जहां संभव हो वहां कॉन्स्ट एफएन का अनुमान लगाया जाएगा और डॉक्स में भी परिलक्षित होगा (और इसके लिए आवश्यक है कि कॉल किए गए फ़ंक्शन भी कॉन्स्ट एफएन हों), यदि कोई टोकरा लेखक इस ध्वज को जोड़ता है तो वे सतर्क रहने की प्रतिज्ञा करते हैं वर्जनिंग के बारे में और शायद जंग-सेवर को भी मजबूर किया जा सकता है।

इसे पीछे की ओर करने के बारे में क्या?

कॉन्स्ट fn होने के बजाय, साइड fn रखें।

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

यह पीछे की ओर संगत नहीं है, हालांकि मुझे लगता है कि इसे किसी संस्करण में जोड़ा जा सकता है?

30 मार्च 2018 को 2:43:06 पूर्वाह्न जीएमटी+08:00, "सोनी एल।" सूचनाएं @github.com ने लिखा:

इसे पीछे की ओर करने के बारे में क्या?

कॉन्स्ट fn होने के बजाय, साइड fn रखें।

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

--
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/rust-lang/rust/issues/24111#issuecomment -377333542

--
K-9 मेल के साथ मेरे Android डिवाइस से भेजा गया। मेरे संक्षिप्तता को माफ़ करो।

मुझे लगता है कि बड़ी समस्या यह है कि शुरुआती लोगों के लिए यह एक वास्तविक झटका होगा, क्योंकि अधिकांश प्रोग्रामिंग भाषाएं ऐसा नहीं करती हैं।

@whitequark मैं किसी भी चीज से असहमत हूं जो बस करता है ("दुष्प्रभावों को फेंक दें"), मुझे लगता है कि @ oli-obk भविष्य के विस्तार के बारे में बात कर रहा था, लेकिन जिन चर्चाओं में मैं था, मुझे निम्नलिखित पता है

• हम "निर्धारक साइड-इफेक्ट्स" को अलग कर सकते हैं (जो आपको अशुद्ध डेटा वापस नहीं देते हैं)
• यदि हम उदाहरण के लिए "संकलन-समय पर लॉग डेटा" चाहते हैं तो हमारे पास विशेष एपीआई हो सकते हैं
  
  
  
  • आप किस बाहरी नियतत्ववाद के स्तर के आधार पर यह बहुत कठिन है, क्योंकि वृद्धिशील ऑन-डिमांड संकलन के परिणामस्वरूप लगातार आउटपुट नहीं होगा
  
  
• विशेष रूप से, हम ऐसी किसी भी चीज़ को नहीं छुएंगे जो वर्तमान में मौजूद है और ग्लोबल्स / C FFI का उपयोग करती है

संपादित करें : बस इसलिए चर्चा पटरी से नहीं उतरती है, उदाहरण के लिए:

साइड इफेक्ट्स को फेंकने से कोड अलग तरह से व्यवहार कर सकता है (लिखें और फिर फ़ाइल पढ़ें) अगर इसे कॉन्स्ट या गैर कॉन्स्ट कहा जाता है।

हम (शायद?) इस तरह के दुष्प्रभावों को दूर करने के बारे में सभी @ ओली-ओबीके मिसपोक मान सकते हैं।

हो सकता है कि इस तरह की सुविधा को क्रेट लेवल कॉन्फिग फ्लैग के रूप में लागू किया जा सकता है जिसे क्रेट की जड़ में जोड़ा जा सकता है

यह पिछले सुझावों के दूसरे उदाहरण का एक सबसेट है, https://github.com/rust-lang/rust/issues/24111#issuecomment -376829588 से।
यदि हमारे पास एक स्कोप्ड "कॉन्फ़िगरेशन फ़्लैग" है, तो उपयोगकर्ता को अधिक बारीक-बारीक स्कोप IMO चुनने में सक्षम होना चाहिए।

इसे पीछे की ओर करने के बारे में क्या?
कॉन्स्ट fn होने के बजाय, साइड fn रखें।
यह अभी भी स्पष्ट है (आपको साइड एफएन को कॉल करने के लिए साइड एफएन डालने की जरूरत है, स्पष्ट रूप से संगतता तोड़ना), और अव्यवस्था को हटा देता है। (कुछ) इंट्रिनिक्स और एएसएम के साथ कुछ भी एक साइड एफएन होगा।

https://github.com/rust-lang/rust/issues/24111#issuecomment -376829588 में मैंने यह बताने की कोशिश की कि संपूर्ण पुस्तकालय "सभी const fn " या "सभी side fn हो सकते हैं। ".
यदि यह फ़ंक्शन घोषणाओं पर नहीं था, बल्कि स्कोप किया गया था, तो यह भविष्य के संस्करण में काम कर सकता है।
हालांकि, "शरीर से अनुमान" के बिना, आपको ऑप्ट-इन side fn के लिए भी विशेषता इंटरैक्शन को डिज़ाइन करना होगा, इसलिए आपको कुछ भी हासिल नहीं हो रहा है और आप संभावित रूप से बड़े पैमाने पर घर्षण का परिचय दे रहे हैं।

केंटन वर्दा के "सिंगलटन्स को हानिकारक माना जाता है" की धारा 3.3 यहां प्रासंगिक लगती है (ईमानदारी से, पूरी बात पढ़ने लायक है)।

डीबग लॉगिंग के बारे में क्या?

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

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

यह दिखाने के लिए अनुरूप तर्क दिए जा सकते हैं कि डीबग लॉगिंग पठनीयता, परीक्षण योग्यता या रखरखाव को नुकसान नहीं पहुंचाती है।

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

"हम एक समाधान [डिबगिंग के लिए] का पता लगा सकते हैं" के बारे में मेरा बयान वास्तव में एक संभावित भविष्य एपीआई का जिक्र कर रहा था, जो कि कॉन्स से कॉल करने योग्य है, लेकिन इसमें कुछ प्रकार की छपाई है। प्लेटफ़ॉर्म विशिष्ट प्रिंट संचालन को यादृच्छिक रूप से कार्यान्वित करना (बस हम प्रिंट/डीबग स्टेटमेंट के साथ मौजूदा कोड बना सकते हैं) ऐसा कुछ नहीं है जो एक कॉन्स्ट मूल्यांकनकर्ता को करना चाहिए। यह पूरी तरह से ऑप्ट इन होगा, स्पष्ट रूप से अलग-अलग देखने योग्य व्यवहार नहीं होगा (उदाहरण के लिए कॉन्स eval में चेतावनियां और रनटाइम पर कमांड लाइन/फ़ाइल आउटपुट)। सटीक शब्दार्थ को भविष्य के RFC पर छोड़ दिया जाता है और सामान्य रूप से const fn के लिए पूरी तरह से ऑर्थोगोनल माना जाना चाहिए

क्या const impl Trait और T: const Trait के कोई महत्वपूर्ण नुकसान हैं?

const के आसपास और भी अधिक छिड़काव के अलावा, केवल कुछ विशेषता विधियों को स्थिर किया जा सकता है, जिसके लिए अधिक बारीक नियंत्रण की आवश्यकता होगी। हालांकि मुझे यह निर्दिष्ट करने के लिए एक साफ वाक्यविन्यास के बारे में पता नहीं है। शायद where <T as Trait>::some_method is const ( is एक प्रासंगिक कीवर्ड हो सकता है)।

फिर से, यह const fn के लिए ओर्थोगोनल है।

[u8; SizeOf<T>::Output]

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

वैकल्पिक रूप से, const fns को वास्तव में const बनाएं: कुछ भी const fn का मूल्यांकन किया जाना चाहिए जैसे कि प्रत्येक पैरामीटर एक कॉन्स्ट जेनेरिक था।

इससे उन्हें तर्क करना बहुत आसान हो जाता है, क्योंकि मैं व्यक्तिगत रूप से const fns के बारे में तर्क नहीं कर सकता क्योंकि वे वर्तमान में खड़े हैं। मैं ट्यूरिंग-पूर्ण प्रकार, मैक्रोज़, सामान्य एफएनएस इत्यादि के बारे में तर्क कर सकता हूं, लेकिन मुझे कॉन्स एफएन के बारे में तर्क करना असंभव लगता है, क्योंकि यहां तक ​​​​कि मामूली विवरण भी अपना अर्थ पूरी तरह बदल देते हैं।

चूंकि मामूली विवरण भी अपना अर्थ पूरी तरह से बदल देते हैं।

क्या आप विस्तृत कर सकते हैं? क्या आपका मतलब const fn पॉइंटर्स, const विशेषता सीमा, ... जैसे एक्सटेंशन हैं? क्योंकि मुझे केवल const fn प्रस्ताव में कोई मामूली विवरण नहीं दिख रहा है।

वैकल्पिक रूप से, const fns को वास्तव में const बनाएं: कुछ भी const fn का मूल्यांकन किया जाना चाहिए जैसे कि प्रत्येक पैरामीटर एक कॉन्स्ट जेनेरिक था।

संकलन-समय पर हम यही कर रहे हैं। बस रनटाइम पर फ़ंक्शन का उपयोग किसी अन्य फ़ंक्शन की तरह किया जाता है।

समस्या यह है कि कोई भी मामूली विवरण const eval को रनटाइम eval में बदल सकता है। यह पहली बार में एक बड़ा सौदा नहीं लग सकता है, लेकिन यह हो सकता है ।

मान लीजिए कि फ़ंक्शन कॉल वास्तव में लंबी है क्योंकि यह सभी कॉन्स्ट fns है? और आप इसे कई पंक्तियों में विभाजित करना चाहते हैं।

तो आप कुछ let s जोड़ें।

अब आपका प्रोग्राम चलने में 20 गुना अधिक समय लेता है।

@ SonyEx2 सरणियों का आकार ( $N में [u8; $N] ) हमेशा संकलन-समय पर मूल्यांकन किया जाता है। यदि वह व्यंजक गैर- const है, तो संकलन विफल हो जाएगा। इसके विपरीत, let x = foo() रनटाइम पर foo $ को कॉल करेगा चाहे वह const fn हो या नहीं (मॉड्यूल ऑप्टिमाइज़र की इनलाइनिंग और निरंतर प्रसार, लेकिन यह const fn से पूरी तरह से अलग है ) यदि आप संकलन-समय पर कुछ अभिव्यक्ति के मूल्यांकन के परिणाम का नाम देना चाहते हैं तो आपको const आइटम की आवश्यकता है।

अब आपका प्रोग्राम चलने में 20 गुना अधिक समय लेता है।

ऐसा बिल्कुल नहीं है कि const fn कैसे काम करता है!

यदि आप एक फ़ंक्शन const fn घोषित करते हैं और आप इसके अंदर let बाइंडिंग जोड़ते हैं, तो आपका कोड संकलन बंद कर देता है।

यदि आप const को const fn $ से हटाते हैं, तो यह एक ब्रेकिंग परिवर्तन है और उस फ़ंक्शन के सभी उपयोगों को तोड़ देगा जैसे const , static या सरणी लंबाई। आपका कोड जो रनटाइम कोड था और const fn चला था, कभी भी संकलन-समय पर नहीं चलेगा। यह सिर्फ एक सामान्य रनटाइम फ़ंक्शन कॉल है, इसलिए यह धीमा नहीं होता है।

संपादित करें: @SimonSapin ने मुझे इसके लिए हराया: D

यदि संभव हो तो संकलन-समय पर कॉन्स्ट fn का मूल्यांकन करें।

अर्थात्,

const fn random() -> i32 {
    4
}

fn thing() -> i32 {
    let i = random(); // the RHS of this binding is evaluated at compile-time, there is no call to random at runtime.
}

अब मान लें कि आपके पास एक const fn है जो तर्क लेता है। संकलन-समय पर इसका मूल्यांकन किया जाएगा:

fn thing() {
    let x = const_fn_with_1_arg(const_fn_returns_value());
}

इससे रनटाइम पर const_fn_with_1_arg का मूल्यांकन किया जाएगा:

fn thing() {
    let x = const_fn_returns_value();
    let y = const_fn_with_1_arg(x); // suddenly your program takes 20x longer to run, and compiles 20x faster.
}

@eddyb मुझे आश्चर्य है कि क्या डिजाइन चिंता को इस अवलोकन द्वारा हल किया जा सकता है कि "न्यूनतम कॉन्स्ट एफएन" सभी संभावित भविष्य के एक्सटेंशन के साथ संगत है? यानी मेरी समझ यह है कि हम स्थिर करना चाहते हैं

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

ऐसा लगता है कि यह किसी भी "लक्षणों के लिए स्थिरांक प्रभाव" डिजाइनों के साथ पूरी तरह से संगत है। यह "अनुमानित कॉन्स्ट" डिज़ाइन के साथ भी संगत है, क्योंकि हम बाद में const वैकल्पिक बना सकते हैं।

क्या कोई वैकल्पिक भविष्य के डिजाइन हैं जो वर्तमान "न्यूनतम कास्ट एफएन" प्रस्ताव के साथ असंगत हैं?

@nrc

ध्यान दें कि rfcbot ने आपकी everything-const चिंता दर्ज नहीं की है (प्रति टिप्पणी एक चिंता!) हालांकि, यह डिजाइन चिंता का एक सबसेट प्रतीत होता है, जिसे मेरी पिछली टिप्पणी (TL; DR: वर्तमान न्यूनतम प्रस्ताव) द्वारा संबोधित किया गया है। सब कुछ के साथ पूरी तरह से संगत है, हम भविष्य में const कीवर्ड को वैकल्पिक बना सकते हैं)।

जहां तक ​​प्राथमिकता/नतीजे की चिंता का सवाल है, मैं उन बातों का दस्तावेजीकरण करना चाहता हूं जिन पर हमने हर समय चर्चा की है, और जिन्हें हमने पहले ही दस्तावेज नहीं किया है:

• const fn foo(x: i32) -> i32 { body } const FOO: i32 = body; से अधिक एक अपेक्षाकृत मामूली जोड़ है, इसलिए गिरावट का जोखिम छोटा है। यही है, अधिकांश कोड जो वास्तव में const fn लागू करता है, पहले से ही स्थिर कंपाइलर में कड़ी मेहनत कर रहा है (अस्वीकरण: यह कुछ ऐसा है जिसे मैंने @ ओली-ओबीके से सुना है, मैंने गलत सुना होगा)।

• एम्बेडेड वर्किंग ग्रुप बुरी तरह से कॉन्स्टेबल चाहता है :)

इसके अतिरिक्त, ध्यान दें कि const fn को स्थिर नहीं करने से पुस्तकालयों में उप इष्टतम API का प्रसार होता है, क्योंकि उन्हें const fns की कमी के आसपास काम करने के लिए ATOMIC_USIZE_INIT जैसी तरकीबों का उपयोग करना पड़ता है।

चलो मैं = यादृच्छिक (); // इस बाध्यकारी के आरएचएस का संकलन-समय पर मूल्यांकन किया जाता है, रनटाइम पर यादृच्छिक पर कोई कॉल नहीं होता है।

नहीं, ऐसा बिल्कुल नहीं हो रहा है। यह हो सकता है (और llvm शायद ऐसा कर रहा है), लेकिन आप किसी भी कंपाइलर ऑप्टिमाइज़ेशन की उम्मीद नहीं कर सकते हैं जो वास्तव में होने वाली हेरिस्टिक्स पर निर्भर करता है। यदि आप संकलन-समय पर कुछ गणना करना चाहते हैं, तो इसे const में चिपका दें, और आपको वह गारंटी मिलती है।

तो const fn केवल एक कॉन्स में मूल्यांकन किया जाता है, और यह मूल रूप से अन्यथा बेकार है?

फिर कॉन्स्टेबल और नॉन-कास्ट fn को सख्ती से अलग क्यों नहीं किया गया?

देखें कि शब्दार्थ एक गड़बड़ है क्योंकि वे जानबूझकर संकलन-समय और रनटाइम सामग्री को मिलाते हैं।

तो const fn केवल एक कॉन्स में मूल्यांकन किया जाता है, और यह मूल रूप से अन्यथा बेकार है?

वे बेकार नहीं हैं, उन्हें किसी अन्य फ़ंक्शन की तरह रनटाइम पर निष्पादित किया जाता है। इसका मतलब यह है कि आपको रस्ट के विभिन्न "उपभाषाओं" का उपयोग करने की आवश्यकता नहीं है, यह इस बात पर निर्भर करता है कि आप एक कॉन्स्टेबल मूल्यांकन में हैं या नहीं।

फिर कॉन्स्टेबल और नॉन-कास्ट fn को सख्ती से अलग क्यों नहीं किया गया?

const fn के लिए संपूर्ण प्रेरणा इस अलगाव को न रखना है। अन्यथा हमें सभी प्रकार के कार्यों की नकल करने की आवश्यकता होगी: AtomicUsize::new() + AtomicUsize::const_new() , भले ही दोनों निकाय समान हों।

क्या आप वास्तव में libcore का 90% दो बार लिखना चाहते हैं, एक बार const eval के लिए और एक बार रनटाइम के लिए? वही शायद कई अन्य बक्से के लिए जाता है।

मैं सोच रहा था AtomicUsize::Of<value> । और हाँ, मुझे अज्ञात गारंटियों के बजाय सब कुछ दो बार लिखना होगा। (साथ ही यह इस आधार पर अलग तरह से व्यवहार नहीं करेगा कि कुछ स्थिर किया जा रहा है या नहीं।)

क्या आप कास्ट मूल्यांकन (रिकर्सिव कॉन्स एफएन के लिए) की गारंटी के लिए कॉन्स एफएन में कॉन्स घोषित कर सकते हैं? या क्या आपको कॉन्स्ट जेनरिक के माध्यम से जाने की ज़रूरत है? आदि।

@ SonyEx2 एक उदाहरण के रूप में कि const fn का लाभ उठाने के लिए आपका उदाहरण कैसे लिखा जाना चाहिए और यदि कोई फ़ंक्शन गैर- const हो जाता है तो संकलन समय त्रुटि में बदल जाता है:

fn thing() {
    const x: u32 = const_fn_returns_value();
    const y: u32 = const_fn_with_1_arg(x);
}

(खेल के मैदान पर पूरा उदाहरण चल रहा है)

थोड़ा कम एर्गोनोमिक क्योंकि कोई प्रकार का अनुमान नहीं है, लेकिन कौन जानता है, यह भविष्य में बदल सकता है।

अज्ञात गारंटी की तुलना में।

क्या आप इतने दयालु होंगे और कुछ उदाहरण देंगे जहां आपको लगता है कि कुछ अस्पष्ट है?

क्या आप कास्ट मूल्यांकन (रिकर्सिव कॉन्स एफएन के लिए) की गारंटी के लिए कॉन्स एफएन में कॉन्स घोषित कर सकते हैं? या क्या आपको कॉन्स्ट जेनरिक के माध्यम से जाने की ज़रूरत है? आदि।

const fn का बिंदु संकलन समय पर चीजों का जादुई मूल्यांकन नहीं करना है। यह संकलन समय पर चीजों का मूल्यांकन करने में सक्षम होना है।

संकलन-समय पर चीजों का जादुई मूल्यांकन पहले से ही हो रहा है क्योंकि rustc llvm पर आधारित था। तो ... ठीक उसी समय जब इसे ocaml में लागू किया जाना बंद हो गया। मुझे नहीं लगता कि कोई भी जंग से निरंतर प्रसार को हटाना चाहता है।

const fn किसी भी तरह से निरंतर प्रसार को प्रभावित नहीं करता है। यदि आपके पास कोई ऐसा फ़ंक्शन था जिसे गलती से प्रचारित किया जा सकता है, और llvm ने ऐसा किया है, और आपने उस फ़ंक्शन को इस तरह से बदल दिया है कि यह अब प्रचार योग्य नहीं है, तो llvm ऐसा करना बंद कर देगा। यह किसी फ़ंक्शन में const संलग्न करने से पूरी तरह स्वतंत्र है। llvm के लिए const fn और fn के बीच कोई अंतर नहीं है।

साथ ही जब आप const को fn से जोड़ते हैं तो rustc अपने व्यवहार को बिल्कुल भी नहीं बदलता है (यह मानते हुए कि फ़ंक्शन एक वैध कॉन्स्ट fn है और इस प्रकार ऐसा करने के बाद भी संकलित होता है)। यह आपको इस फ़ंक्शन को अभी से स्थिरांक में कॉल करने की अनुमति देता है ।

मैं एलएलवीएम के बारे में नहीं सोच रहा हूं, मैं जंग के बारे में सोच रहा हूं। एलएलवीएम यहां मेरे लिए कोई मायने नहीं रखता।

@ SonyEx2

यदि संभव हो तो संकलन-समय पर कॉन्स्ट fn का मूल्यांकन करें।

यह सही नहीं है। const fn , जब किसी विशेष संदर्भ में कॉल किया जाता है, तो संकलन-समय पर मूल्यांकन किया जाएगा। यदि यह संभव नहीं है, तो एक कठिन त्रुटि है। अन्य सभी संदर्भों में, const भाग बिल्कुल भी मायने नहीं रखता।

ऐसे संदर्भों के उदाहरण जिनके लिए const fn की आवश्यकता होती है, वे सरणी लंबाई हैं। आप [i32; 15] लिख सकते हैं। आप [i32; 3+4] भी लिख सकते हैं क्योंकि कंपाइलर 7 की गणना कर सकता है। आप [i32; read_something_from_network()] नहीं लिख सकते, क्योंकि इसका कोई मतलब कैसे होगा? इस प्रस्ताव के साथ, आप लिख सकते हैं [i32; foo(15)] अगर foo है const fn , जो सुनिश्चित करता है कि यह नेटवर्क को एक्सेस करने जैसा है और कम पसंद है।

यह उस कोड के बारे में बिल्कुल नहीं है जो प्रोग्राम चलने पर चल सकता है या चल सकता है। कोई "शायद संकलन-समय पर मूल्यांकन" नहीं है। बस "संकलन-समय पर मूल्यांकन करना है या संकलन को रोकना है"।

कृपया आरएफसी भी पढ़ें: https://github.com/rust-lang/rfcs/blob/master/text/0911-const-fn.md

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

इस दृष्टिकोण के तहत, मूल्यांकन संकलन-समय पर होगा यदि परिणाम const चर के लिए बाध्य है, और अन्यथा रन-टाइम पर। यह अधिक वांछनीय लगता है, क्योंकि यह कॉल करने वाले को (कैली के बजाय) नियंत्रण देता है जब फ़ंक्शन का मूल्यांकन किया जाता है।

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

हम्म, हाँ यह एक समस्या है ...

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

2 संपादित करें: मुझे लगता है कि पिछड़ा संगतता तोड़ देगा, हालांकि, यह एक गैर स्टार्टर है। साइड-ट्रैक के लिए क्षमा करें।

तो ... चर्चा मर गई है। आइए संक्षेप करें:

rfcbot टिप्पणी है https://github.com/rust-lang/rust/issues/24111#issuecomment -376649804

वर्तमान चिंताएं

• यह प्राथमिकता नहीं है, और 2018 की रिलीज़ ने हमारी प्लेटों पर पहले से ही पर्याप्त डाल दिया है
• हम सब कुछ const चिह्नित करना शुरू करते हैं, जो कष्टप्रद है
• क्या यह वह डिज़ाइन है जिसे हम प्रतिबद्ध करना चाहते हैं?

मैं वास्तव में प्राथमिकता वाली चीज़ + फॉलआउट चिंता के बारे में बात नहीं कर सकता, सिवाय इसके कि const fn रात में लंबे समय तक बेक किया गया है

अन्य दो बिंदु निकट से संबंधित हैं। @eddyb का डिज़ाइन (https://github.com/rust-lang/rust/issues/24111#issuecomment-376829588 जैसा कि मैंने इसे समझा) const fn नहीं है, बल्कि इसके बजाय एक #[const] है

#[const]
mod foo {
    pub fn square(i: i32) -> i32 { i * i }
}
#[const]
fn bar(s: &str) -> &str i{ s }
#[const]
fn boo() -> fn(u32) -> u32 { meh }
fn meh(u: u32) -> u32 { u + 1 }

और जो कुछ भी इसके साथ चिह्नित है, उसमें पुनरावर्ती रूप से चला जाता है, इसलिए #[const] मॉड्यूल के अंदर कोई भी फ़ंक्शन #[const] fn है। #[const] fn के अंदर घोषित एक फ़ंक्शन भी #[const] fn है।

यह आवश्यक एनोटेशन की संख्या को कम करता है, क्योंकि कुछ क्रेट केवल #![const] को lib.rs में थप्पड़ मार देंगे और इसके साथ किया जाएगा।

उस डिज़ाइन के साथ मुझे दिखाई देने वाली समस्याएं (लेकिन वे मुद्दे भी अक्सर मौजूद होते हैं const fn ):

• ऑप्ट-आउट समर्थन की आवश्यकता हो सकती है, क्योंकि आप कुछ गैर-कॉन्स्ट फ़ंक्शन को अन्यथा #[const] मॉड्यूल ट्री के अंदर घोषित करने में सक्षम होना चाहते हैं।
• फ़ंक्शन पॉइंटर्स #[const] fn तर्क/वापसी प्रकार की स्थिति में #[const] fn होने की आवश्यकता है?
  
  
  
  • फिर से, ऑप्ट-आउट करना आवश्यक होगा
  
  

हमें इन चीजों के बारे में सोचने की ज़रूरत है, इसलिए हम एक ऐसी प्रणाली तैयार नहीं करते हैं जो भविष्य के संस्करण के साथ असंगत हो, जहां हम एक कॉन्स्टेबल के दौरान फ़ंक्शन पॉइंटर्स के माध्यम से फ़ंक्शन को कॉल करने में सक्षम होना चाहते हैं।

ध्यान दें कि मैंने एक निश्चित डिजाइन का प्रस्ताव नहीं दिया था, लेकिन केवल कुछ ज्ञात प्रशंसनीय दिशाओं को सूचीबद्ध किया था।
मूल विचार एक सामान्यीकृत "एक्सपोज़ बॉडी ऑफ़ फंक्शन" विशेषता थी, जो const तक सीमित नहीं थी, लेकिन कई संभावित विविधताएँ हैं, और उनमें से कुछ अच्छी भी हो सकती हैं ।

संपादित करें : (इसके बारे में भूलना नहीं चाहते) @solson मुझे दिखा रहा था कि कैसे लीन के पास @pattern जैसे गुण हैं जो स्वचालित रूप से फ़ंक्शन के शरीर से विभिन्न चीजें प्राप्त करते हैं।

@ oli-obk मुझे लगता है कि हमें विशेषताओं के साथ नहीं जाना चाहिए, क्योंकि unsafe एक विशेषता का उपयोग नहीं करता है।
साथ ही, async वर्तमान में भी नहीं है। और अगर हम try fn दिए गए try { .. } ब्लॉक पेश करते हैं, तो हमारे पास एक और चीज है जो विशेषता आधारित नहीं है। मुझे लगता है कि हमें जितना संभव हो उतना सुसंगत रहने की कोशिश करनी चाहिए जो प्रभाव-जैसी wrt हो। विशेषताओं का उपयोग कर रहे हैं या नहीं। #[target_feature(..)] समग्र स्थिरता में एक झुर्रियां डालता है।

पुनश्च: आप const mod { .. } का उपयोग const mod { .. } #![const] समान प्रभाव प्राप्त करने के लिए कम या ज्यादा कर सकते हैं। यह try mod , async mod , unsafe mod पर भी लागू हो सकता है।

मैं हमेशा विशेष प्रकार की चीजों को करने की ओर झुकता रहूंगा।

struct SizeOf<T>;

impl<T> SizeOf<T> {
    const intrisic Result: usize;
}

नए सिंटैक्स के साथ नई अवधारणाओं को सीखने की तुलना में मौजूदा सिंटैक्स का उपयोग करके नए प्रकार सीखना आसान है।

और हम बाद में रनटाइम पर टाइप सिस्टम का समर्थन कर सकते हैं।

fn sq(v: i32) -> i32 {
    Square<v>::Result
}

संकलन समय पर प्रकार, कास्ट जेनरिक या तो संकलन समय पर या रनटाइम पर।

तो ... मैं इस तथ्य को अनदेखा करने का सुझाव दे रहा हूं कि वहां संभवतः बेहतर डिज़ाइन हो सकता है, क्योंकि हमारे पास एक डिज़ाइन है जो है

1. तर्क करने में आसान
2. किसी भी अधिक अनुमेय डिजाइन के अनुकूल अग्रेषित करें
3. ऐतिहासिक रूप से अस्थिर कोड में बड़ी सफलता के लिए उपयोग किया गया है, मुख्य शिकायत पर्याप्त विशेषताएं नहीं है।
4. एनोटेशन को अभी तक एनोटेट किए गए कार्यों में जोड़ने का सुझाव देने के लिए लाइन किया जा सकता है जिसमें एक निकाय है जो इसे जोड़ने की अनुमति देता है।
5. मैं व्यक्तिगत रूप से, जैसा कि मर्ज अनुरोध में पोस्ट किया गया है, मैं एकमात्र डिज़ाइन के रूप में देखता हूं जिसे हम एक और बहु-वर्ष की कोशिश अवधि के बिना स्थिर कर सकते हैं।
6. प्रत्येक के लिए कस्टम कोड की आवश्यकता के बजाय, कोड को रनटाइम और कॉन्स्टेबल कोड के बीच साझा करने की अनुमति देता है

और हम बाद में रनटाइम पर टाइप सिस्टम का समर्थन कर सकते हैं।

यह निर्भर टाइपिंग है, जो बहुत दूर है , जबकि रनटाइम पर const fn को कॉल करना आज ठीक काम करता है।

@ ओली-ओबीके लक्षणों के बारे में क्या? मैं const fn को स्थिर नहीं करना चाहता, बिना यह जाने कि हम विशेषता विधियों के लिए क्या करने जा रहे हैं जो कि const fn हैं जो केवल कुछ विशेषता के impl s में हैं।

@eddyb ऐसा लगता है कि मुझे नई कॉन्स सीमाओं और विधियों के लेखन में तेजी लानी चाहिए। :)

@Centril मेरा कहना है कि विशेषता प्रस्ताव (चाहे कीवर्ड का उपयोग कर रहे हों या नहीं) के परिणामस्वरूप विशेषता विधियों से निपटने के लिए बहुत अधिक भिन्न दृष्टिकोण होगा, और हमें इसकी तुलना करनी होगी।
वर्तमान const fn दृष्टिकोण सरल और एक्स्टेंसिबल लग सकता है, लेकिन वास्तव में विस्तारित होने पर नहीं ।

जेनेरिक कॉन्स + कॉन्स्ट जेनरिक:

intrinsic const SizeOf<T>: usize;

const Pow<const V: usize>: usize = V*V;

@eddyb मेरे मन में कई समाधान हैं जो कॉन्स्ट fn डिज़ाइन के साथ पूरी तरह से संगत हैं। मैं इसे लिखूंगा।

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

@rfcbot चिंता रनटाइम-पॉइंटर-पते

एक अलग मुद्दे पर, यह सवाल उठा कि क्या हम const fn से संदर्भात्मक पारदर्शिता चाहते हैं, और कच्चे पॉइंटर्स के पतों को गैर-निर्धारणवाद ओरेकल के रूप में इस्तेमाल करने की समस्या सामने आई: https://github.com/rust- लैंग/रस्ट/इश्यू/49146#इश्यू कमेंट -386727325. वहाँ एक समाधान उल्लिखित है, लेकिन इसमें स्थिरीकरण से पहले कुछ कच्चे सूचक संचालन unsafe (सुनिश्चित नहीं हैं कि उनमें से कितने को आज भी अनुमति दी गई है) बनाना शामिल है।

@eddyb क्या E0018 const fn s पर भी लागू नहीं होगा?

सी वे यह है कि ऑब्जेक्ट पॉइंटर्स को सभी 0 होने की अनुमति है जब तक कि सापेक्ष (यानी किसी ऑब्जेक्ट के अंदर) और किसी भी तरह रनटाइम पर ट्रैक न किया जाए।

मुझे यकीन नहीं है कि जंग सी के एलियासिंग नियमों का समर्थन करता है।

@sgrif स्थिरांक के बारे में उत्सर्जित कई त्रुटियां जल्दी या बाद में दूर होने जा रही हैं - मिरी परवाह नहीं है कि एक मूल्य को किस प्रकार देखा जाता है, एक अमूर्त स्थान जो usize मान में है, अभी भी एक अमूर्त स्थान है (और इसे एक पॉइंटर पर कास्ट करने से आपको मूल पॉइंटर वापस मिल जाता है)।

मैंने अभी जांच की है और अभी के लिए , दोनों कास्टिंग पॉइंटर्स को पूर्णांक, और पॉइंटर के बीच तुलना ऑपरेटर, निरंतर संदर्भों में प्रतिबंधित हैं। हालाँकि, यह वही है जो हमने सोचा था , मुझे अभी भी डर लग रहा है।

@eddyb मेला काफी। हालांकि, मुझे उम्मीद है कि आपकी कोई भी चिंता जो const fn हिट हुई है, वह आज पहले ही किसी भी const ब्लॉक को हिट कर चुकी है।

@sgrif अंतर const है (यहां तक ​​कि संबद्ध const s जो सामान्य प्रकार के मापदंडों पर निर्भर करता है) का पूरी तरह से संकलन-समय पर, मिरी के तहत मूल्यांकन किया जाता है, जबकि const fn एक गैर- रनटाइम कॉल के लिए const fn ।
इसलिए यदि हम वास्तव में संदर्भात्मक पारदर्शिता चाहते हैं, तो हमें यह सुनिश्चित करने की आवश्यकता है कि हम (सुरक्षित कोड में, कम से कम) ऐसी चीजों की अनुमति नहीं देते हैं जो रनटाइम गैर-नियतत्ववाद का कारण बन सकती हैं, भले ही वे मिरी के तहत ठीक हों ।
जिसका शायद मतलब है कि फ्लोट के बिट्स प्राप्त करना भी एक समस्या है, क्योंकि जैसे NaN पेलोड।

चीजें जो आपको मिरी में करने पर विचार करना चाहिए:

सभी पॉइंटर्स 0 हैं जब तक कि सापेक्ष न हो। जैसे:

#[repr(C)]
struct X {
    a: usize,
    b: u8,
}
let x = X { a: 1, b: 2 };
let y: usize = 3;
assert_eq!(&x as *const _ as usize, 0);
assert_eq!(&x.a as *const _ as usize, 0);
assert_eq!(&x.b as *const _ as usize, 8);
assert_eq!(&y as *const _ as usize, 0);

फिर आप उन्हें मिरी मूल्यांकन पर ट्रैक करते हैं। कुछ चीजें यूबी होंगी, जैसे पॉइंटर से वापस पॉइंटर का उपयोग करने के लिए जाना, लेकिन उन्हें अस्वीकार करना आसान है (पॉइंटर रूपांतरणों के उपयोग पर प्रतिबंध लगाएं। चूंकि आप पहले से ही रनटाइम/मूल्यांकन समय पर पॉइंटर्स ट्रैक कर रहे होंगे)।

फ्लोट बिट्स के लिए, NaN सामान्यीकरण?

मुझे लगता है कि वे दोनों पूरी चीज को निर्धारक बना देंगे।

जिसका शायद मतलब है कि फ्लोट के बिट्स प्राप्त करना भी एक समस्या है, क्योंकि जैसे NaN पेलोड।

मुझे लगता है कि पूर्ण संदर्भात्मक पारदर्शिता के लिए, हमें सभी फ्लोट संचालन को असुरक्षित बनाना होगा।

फ़्लोटिंग पॉइंट नियतत्ववाद कठिन है

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

मैं पहले स्थिर स्थिरांक fn सुविधा के लिए अभी तक बिना फ़्लोट के सहमत हूँ, जब तक कि इस बात पर कोई निर्णय नहीं हो जाता है कि संदर्भात्मक पारदर्शिता कितनी महत्वपूर्ण है, लेकिन उस चर्चा से const fn को धीमा या अवरुद्ध नहीं करना चाहेंगे।

यहां सबसे महत्वपूर्ण बात यह है कि LLVM का ऑप्टिमाइज़र फ्लोट संचालन के क्रम को बदल सकता है और करता है और साथ ही फ़्यूज़ ऑपरेशन भी करता है जिसके लिए इसका एक संयुक्त ओपकोड है। ये परिवर्तन ऑपरेशन के परिणाम को प्रभावित करते हैं, भले ही वास्तविक अंतर मामूली हो।

फ़्यूज़िंग ऑपरेशंस (मुझे लगता है कि आप mul-add का उल्लेख करते हैं) की अनुमति नहीं है/फास्ट-मैथ फ्लैग के बिना ठीक से नहीं किया जाता है क्योंकि यह परिणामों के दौर को बदल देता है। LLVM "डिफ़ॉल्ट फ़्लोटिंग पॉइंट वातावरण" द्वारा निर्धारित सीमा के भीतर IEEE अनुरूप हार्डवेयर को लक्षित करते समय फ़्लोटिंग पॉइंट ऑपरेशंस के सटीक शब्दार्थ को संरक्षित करने के लिए बहुत सावधान है।

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

दूसरा प्रमुख मामला जो मुझे पता है कि कंपाइलर का निर्णय फ़्लोटिंग पॉइंट परिणामों के लिए अंतर कर सकता है, x87 (प्री-एसएसई) कोड में स्पिल और रीलोड का स्थान है। और यह ज्यादातर एक मुद्दा है क्योंकि x87 डिफ़ॉल्ट रूप से मध्यवर्ती परिणामों के लिए 80 बिट तक और दुकानों पर 32 या 64 बिट के लिए राउंड करता है। सही ढंग से गोल परिणाम प्राप्त करने के लिए प्रत्येक FPU निर्देश से पहले राउंडिंग मोड को ठीक से सेट करना संभव है, लेकिन यह वास्तव में व्यावहारिक नहीं है और इसलिए (मेरा मानना ​​​​है) LLVM इसका समर्थन नहीं करता है।

पूर्ण रेफ़रेंशियल पारदर्शिता पर

मेरा विचार है कि हमें पूर्ण संदर्भात्मक पारदर्शिता के साथ जाना चाहिए क्योंकि यह सुविधा / पूर्णता पर सुरक्षा / शुद्धता चुनने के समग्र रस्ट संदेश के साथ है।

रेफ़रेंशियल ट्रांसपेरेंसी बहुत सारे रीजनिंग फ़ायदे जोड़ती है जैसे कि इक्वेशनल रीजनिंग को सक्षम करना (नीचे तक, लेकिन तेज़ और ढीला रीज़निंग नैतिक रूप से सही है )।

हालांकि, निश्चित रूप से कमियां wrt हैं। पूर्णता wrt पर हारना। सीटीएफई। इसके द्वारा मेरा मतलब है कि एक संदर्भित पारदर्शी const fn तंत्र संकलन समय पर उतना मूल्यांकन करने में सक्षम नहीं होगा जितना कि गैर-रेफ-पारदर्शी const fn योजना कर सकती है। उन लोगों से जो संदर्भात्मक पारदर्शिता के साथ नहीं चिपके रहने का प्रस्ताव रखते हैं, मैं उनसे इस प्रस्ताव के खिलाफ अधिक से अधिक ठोस उपयोग के मामले प्रदान करने के लिए कहूंगा ताकि हम ट्रेड-ऑफ का मूल्यांकन कर सकें।

ठीक है, ऐसा लगता है कि आप एलएलवीएम बिंदु के बारे में सही हैं, यह वास्तव में कम्प्यूटेशनल रूप से गलत संचालन से बचने लगता है जब तक कि आप तेज़ गणित मोड को सक्षम नहीं करते।

हालांकि, अभी भी राज्य का एक समूह है कि फ़्लोटिंग पॉइंट ऑपरेशंस आंतरिक परिशुद्धता की तरह निर्भर करता है। क्या सीटीएफई फ्लोट मूल्यांकनकर्ता रनटाइम पर आंतरिक परिशुद्धता मान जानता है?

इसके अलावा, स्मृति में मूल्यों को फैलाने के दौरान हम आंतरिक मूल्य को आईईईई 754 प्रारूप में परिवर्तित करते हैं और इस प्रकार सटीकता बदलते हैं। यह परिणाम को भी प्रभावित कर सकता है, और कंपाइलर द्वारा स्पिलिंग प्रदर्शन करने वाला एल्गोरिदम निर्दिष्ट नहीं है, है ना?

@ est31 ध्यान दें कि मुझे लगता है कि संकलन-समय और रनटाइम व्यवहार भिन्न होने पर हमें परवाह नहीं है, केवल दोहराए गए कॉल (जमे हुए ऑब्जेक्ट ग्राफ़ के साथ) सुसंगत और वैश्विक दुष्प्रभाव-मुक्त हैं।

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

तो यहां लक्ष्य यह गारंटी देना है कि रन-टाइम पर const fn नियतात्मक और साइड-इफेक्ट मुक्त है, भले ही मिरी निष्पादन के दौरान इसके बारे में त्रुटि करे , कम से कम अगर const fn पूरी तरह से सुरक्षित है कोड? मैंने कभी इसे महत्वपूर्ण नहीं माना, टीबीएच। यह एक बहुत मजबूत आवश्यकता है, और वास्तव में हमें कम से कम पीटीआर-टू-इंट और फ्लोट-टू-बिट्स असुरक्षित बनाना होगा, जिसे समझाना मुश्किल होगा। ओटीओएच, हमें कच्चे सूचक तुलना को असुरक्षित भी बनाना चाहिए और मुझे इसके बारे में खुशी होगी: डी

इसके लिए प्रेरणा क्या है? ऐसा लगता है कि हम शुद्धता और एक प्रभाव प्रणाली को फिर से पेश करने की कोशिश कर रहे हैं, जो चीजें हैं जो जंग एक बार थी और खो गई थी, शायद इसलिए कि उन्होंने अपना वजन नहीं उठाया (संपादित करें: या क्योंकि यह सभी अलग करने के लिए पर्याप्त लचीला नहीं था जिन चीज़ों के लिए लोग इसका उपयोग करना चाहते थे, उन्हें देखें https://mail.mozilla.org/pipermail/rust-dev/2013-April/003926.html)।

ptr-to-int सुरक्षित है यदि यह किसी ऑब्जेक्ट की शुरुआत से कनवर्ट करता है, और आप int-to-ptr को विफल होने देते हैं। यह 100% नियतात्मक होगा। और हर कॉल एक ही परिणाम देगा।

ptr-to-int सुरक्षित है, int-to-ptr असुरक्षित है। ptr-to-int को const मूल्यांकन में "अप्रत्याशित" परिणामों की अनुमति दी जानी चाहिए।

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

ptr-to-int सुरक्षित है यदि यह किसी ऑब्जेक्ट की शुरुआत से कनवर्ट करता है, और आप int-to-ptr को विफल होने देते हैं। यह 100% नियतात्मक होगा। और हर कॉल एक ही परिणाम देगा।

आप कैसे सुझाव देते हैं कि हम इसे रन-टाइम पर लागू करें? (&mut *Box::new(...)) as usize अभी एक गैर-नियतात्मक कार्य है और सभी const fn होना चाहिए। तो आप कैसे सुझाव देते हैं कि हम सुनिश्चित करें कि यह "रन-टाइम पर संदर्भित रूप से पारदर्शी" है, हमेशा एक ही मूल्य को वापस करने के अर्थ में?

Box::new को VM में एक ट्रैक किए गए पॉइंटर को वापस करना चाहिए।

रूपांतरण का परिणाम 0 होगा, संकलन-समय पर (यानी एक कास्ट मूल्यांकन में)। गैर-कॉन्स्ट मूल्यांकन में, यह जो कुछ भी वापस करेगा।

एक ट्रैक किया गया सूचक इस तरह काम करता है:

आप एक सूचक आवंटित करते हैं, और आप इसे असाइन करते हैं। जब आप इसे असाइन करते हैं, तो VM पॉइंटर मान को 0 पर सेट करता है, लेकिन पॉइंटर का मेमोरी एड्रेस लेता है, और इसे लुकअप टेबल से जोड़ता है। जब आप पॉइंटर का उपयोग करते हैं, तो आप लुकअप टेबल पर जाते हैं। जब आप पॉइंटर का मान प्राप्त करते हैं (यानी बाइट्स जो इसे बनाते हैं), तो आपको 0 मिलता है। मान लें कि यह किसी ऑब्जेक्ट का बेस पॉइंटर है।

Box::new को VM में एक ट्रैक किए गए पॉइंटर को वापस करना चाहिए।

हम यहां रन-टाइम व्यवहार के बारे में बात कर रहे हैं। जैसा कि, क्या होता है जब इसे बाइनरी में निष्पादित किया जाता है। कोई वीएम नहीं है।

मिरी पहले से ही यह सब ठीक और पूरी तरह से निश्चित रूप से संभाल सकता है।

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

@RalfJung I लिंक्ड https://github.com/rust-lang/rust/issues/49146#issuecomment -386727325 पहले से ही चिंता की टिप्पणी में है, हो सकता है कि वह अन्य संदेशों के तहत खो गया हो - इसमें एक समाधान का विवरण शामिल है @Centril प्रस्तावित ( संचालन unsafe करें और कुछ "सही उपयोगों" को श्वेतसूची में डालें, उदाहरण के लिए offset_of ptr-to-int और NaN-सामान्यीकृत फ्लोट-टू-बिट्स के लिए)।

@eddyb यकीन है, कई समाधान हैं; मैं जो मांग रहा हूं वह प्रेरणा है। मुझे वहां भी नहीं मिला।

साथ ही, आईआरसी से खुद को उद्धृत करते हुए: मुझे लगता है कि हम सही ढंग से तर्क भी दे सकते हैं कि सीटीएफई नियतात्मक है , भले ही पीआरटी-टू-इंट कास्ट की अनुमति हो। वास्तव में किसी भी गैर-नियतात्मकता का निरीक्षण करने के लिए यह अभी भी गैर-सीटीएफई-कोड लेता है (उदाहरण के लिए एक पीआरटी कास्ट के बिट्स को एक इंट में निकालना)।

const fn thing() -> usize {
    (*Box::new(0)) as *const _ as usize
}

const X: usize = thing();
const Y: usize = thing();

एक्स == वाई है?

मेरे सुझाव के साथ, एक्स == वाई।

@ SonyEx2 जो foo as *const _ as usize as *const _ को तोड़ता है जो अभी पूरी तरह से एक शोर है

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

@ SonyEx2 हां, X == Y हमेशा।

हालांकि, अगर आपके पास है:

const fn oracle() -> bool { let x = 0; let y = &x as *const _ as usize; even(y) }

fn main() {
    assert_eq!(oracle(), oracle());
}

फिर main रनटाइम पर घबराहट हो सकती है।

@ राल्फजंग

या क्योंकि यह इतना लचीला नहीं था कि उन सभी अलग-अलग चीजों को कर सके जिन्हें लोग इसके लिए इस्तेमाल करना चाहते थे [..]

वे चीजें क्या थीं? बिना सहमति के इसका मूल्यांकन करना कठिन है।

मुझे लगता है कि हम यह तर्क भी दे सकते हैं कि सीटीएफई नियतात्मक है, तब भी जब पीटीआर-टू-इंट कास्ट की अनुमति है।
[...]
वास्तव में किसी भी गैर-नियतात्मकता का निरीक्षण करने के लिए यह अभी भी गैर-सीटीएफई-कोड लेता है (उदाहरण के लिए एक पीआरटी कास्ट के बिट्स को एक इंट में निकालना)।

हां, संकलन समय पर निष्पादित होने पर const fn अभी भी नियतात्मक है, लेकिन मैं यह नहीं खरीदता कि यह रनटाइम पर नियतात्मक है क्योंकि हमेशा कुछ गैर- const fn (सिर्फ fn ) होंगे const fn का परिणाम रनटाइम पर किसी भी चीज़ के लिए उपयोगी होना है, और फिर वह fn कोड निष्पादित const fn से साइड इफेक्ट का निरीक्षण करेगा।

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

reverse :: [a] -> [a]
reverse []       = []
reverse (x : xs) = reverse xs ++ [x]

putStrLn :: String -> IO ()
getLine :: IO String

main :: IO ()
main = do
    line <- getLine
    let revLine = reverse line
    putStrLn revLine

आप जानते हैं कि revLine में let revLine = reverse line का परिणाम केवल reverse में पारित राज्य पर निर्भर कर सकता है जो कि line है। यह तर्क लाभ और स्वच्छ अलगाव प्रदान करता है।

मुझे आश्चर्य है कि उस समय प्रभाव प्रणाली कैसी दिखती थी ... मुझे लगता है कि हमें एक दिए गए const fn , async fn , आदि की आवश्यकता है। वैसे भी इसे साफ-सुथरा करने और कोड का पुन: उपयोग करने के लिए (कुछ https:// github.com/rust-lang/rfcs/pull/2237 लेकिन कुछ बदलावों के साथ ...) और पैरामीट्रिकिटी इसके लिए एक अच्छा विचार है।

फिल वाडलर और कॉनर मैकब्राइड के अमर शब्दों में:

मैं पावन बनूँ या अपवित्र?
-फिलिप वाडलर [60]

हम कहते हैं 'हां।': शुद्धता स्थानीय स्तर पर बनाने का विकल्प है

https://arxiv.org/pdf/1611.09259.pdf

@ ओली-ओबीके

मैं उस व्यक्ति से ईर्ष्या नहीं करता जिसे इस आश्चर्यजनक व्यवहार का दस्तावेजीकरण करना है कि निष्पादन का परिणाम const fn के लिए भिन्न हो सकता है यदि रनटाइम पर या समान तर्क दिए गए संकलन समय पर निष्पादित किया जाता है।

एक रूढ़िवादी विकल्प के रूप में, मेरा प्रस्ताव है कि हम const fn को संदर्भित रूप से पारदर्शी के रूप में स्थिर करके संदर्भात्मक पारदर्शिता / शुद्धता पर निर्णय में देरी करते हैं, जिससे unsafe (या गैर- const ) का उल्लंघन होता है। यह है, लेकिन हम वास्तव में संदर्भात्मक पारदर्शिता की गारंटी नहीं देते हैं, इसलिए लोग इसे मान भी नहीं सकते।

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

हाँ, लेकिन यह एक स्थिरांक मूल्यांकन नहीं है।

int को ptr में const में कनवर्ट करना एक बड़ी हानि की तरह प्रतीत नहीं होता है। फ़ील्ड ऑफ़सेट प्राप्त करना अधिक महत्वपूर्ण लगता है, और यही मैं संरक्षित करने का प्रयास कर रहा हूं।

@ SonyEx2 फ़ंक्शन में const जोड़ते समय मैं चुपचाप व्यवहार नहीं बदलना चाहता और यह अनिवार्य रूप से आपका सुझाव क्या करेगा।

@centril मैं सहमत हूं, चलो अब रूढ़िवादी काम करते हैं। इसलिए हम इन्हें असुरक्षित नहीं, बल्कि अस्थिर बनाते हैं। इस तरह libstd इसका उपयोग कर सकता है, लेकिन हम बाद में विवरण पर निर्णय ले सकते हैं।

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

यह अभी भी रनटाइम पर वही होगा, कॉन्स केवल कॉन्स्ट टाइम पर चीजों को बदल देगा, जो ... बिना कॉन्स के भी करना संभव नहीं होगा।

कॉन्स्ट fns के लिए अलग-अलग पॉइंटर एलियासिंग नियमों के साथ एक उपभाषा होना ठीक है।

@ Centril @ est31 मुझे यकीन नहीं है कि क्लोरोट्रिफ्लुओरोएथिलीन का किसी भी चीज़ से क्या लेना-देना है (क्या हम उन्हें परिभाषित किए बिना शब्दकोष के एक समूह का उपयोग करने से बच सकते हैं?)

@sgrif https://en.wikipedia.org/wiki/Compile_time_function_execution

@sgrif CTFE (संकलन-समय फ़ंक्शन मूल्यांकन) लंबे समय से रस्ट (इस धागे के वर्षों पुराने भागों सहित) के लिए उपयोग किया जाता है। यह उन शर्तों में से एक है जिसे पहले से ही कहीं केंद्रीय परिभाषित किया जाना चाहिए।

@sgrif lol क्षमा करें, ज्यादातर बार मैं वह व्यक्ति हूं जो सोच रहा है "अब वे कौन से अजीब शब्द उपयोग कर रहे हैं?"। मुझे लगता है कि मैं आईआरसी में @eddyb से बात कर रहा था जब उसने "सीटीएफई" का उल्लेख किया और मुझे उससे पूछना पड़ा कि इसका क्या मतलब है: पी।

इस पृष्ठ पर @eddyb ctrl+f + CTFE इसे परिभाषित करने के लिए कुछ भी नहीं करता है। किसी भी तरह, मैं ज्यादातर इस धारणा पर जा रहा हूं कि हम लोगों को यहां चर्चाओं में भाग लेने के लिए बहुत अधिक खुदाई करने के लिए मजबूर नहीं करना चाहते हैं। "आपको पहले से ही पता होना चाहिए कि इसका क्या अर्थ है" काफी बहिष्कृत आईएमओ है।

@ सेंट्रिल @ est31 धन्यवाद: दिल:

तो... के बारे में कोई विचार

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

क्या संघ क्षेत्र का उपयोग const fn के अंदर भी अस्थिर होना चाहिए?

इस पृष्ठ पर ctrl+f + CTFE इसे परिभाषित करने के लिए कुछ भी नहीं करता है।

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

मैं नहीं चाहता कि कोई भी चर्चा बहिष्कृत हो, लेकिन मुझे नहीं लगता कि CTFE को परिभाषित करने के लिए @ Centril या @ est31 से पूछना उचित है, क्योंकि उनमें से किसी ने भी पहले संक्षिप्त नाम का परिचय नहीं दिया था।
एक समाधान है जो दुर्भाग्य से गिटहब पर काम नहीं करेगा, जिसे मैंने एक निश्चित सबरेडिट में देखा है, जहां एक बॉट एक शीर्ष-स्तरीय टिप्पणी बनाएगा और इसे अद्यतन रखेगा , सभी सामान्य रूप से उपयोग किए जाने वाले शब्दकोषों के विस्तार की सूची के साथ उस सबरेडिट की चर्चा में दिखाई दे रहा है।

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

( मैंने सीटीएफई विकी लिंक को सबसे ऊपर रखा है; अब क्या हम कृपया const fn s पर वापस आ सकते हैं? :P)

क्या कोई CTFE को rustc गाइड शब्दावली में जोड़ सकता है (मैं मोबाइल पर हूँ)?

साथ ही, मुझे लगता है कि हमें न्यूनतम न्यूनतम को स्थिर करना चाहिए और देखना चाहिए कि लोग अभ्यास में क्या करते हैं, जो कि कॉन्स्ट के साथ वर्तमान दृष्टिकोण और अभिव्यक्तियों से मेल खाते हैं।

@सेंट्रिल

मैं उस व्यक्ति से ईर्ष्या नहीं करता जिसे इस आश्चर्यजनक व्यवहार का दस्तावेजीकरण करना है कि निष्पादन का परिणाम const fn के लिए भिन्न हो सकता है यदि रनटाइम पर या समान तर्क दिए गए संकलन समय पर निष्पादित किया जाता है।

आपके द्वारा ऊपर लिखा गया even CTFE समय पर निष्पादित होने पर विफल हो जाएगा क्योंकि यह एक पॉइंटर के बिट्स का निरीक्षण करता है। (हालांकि वास्तव में हम निश्चित रूप से कह सकते हैं कि यह संरेखण के कारण भी है, और यदि समता परीक्षण बिट संचालन के माध्यम से किया जाता है, तो "पूर्ण मिरी" इसे ठीक से करेगा। लेकिन मान लीजिए कि आप पूरे कम से कम महत्वपूर्ण बाइट का परीक्षण कर रहे हैं, न कि केवल आखिरी बिट।)
हम यहां जिस मामले के बारे में बात कर रहे हैं वह एक ऐसा फ़ंक्शन है जो संकलन-समय पर एक दुभाषिया त्रुटि के साथ त्रुटि करता है, लेकिन रन-टाइम पर सफल होता है। अंतर यह है कि क्या फ़ंक्शन निष्पादन भी पूरा करता है। मुझे नहीं लगता कि इसे समझाना मुश्किल है।

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

@ ओली-ओबीके

मैं सहमत हूं, चलो अब रूढ़िवादी बात करते हैं। इसलिए हम इन्हें असुरक्षित नहीं, बल्कि अस्थिर बनाते हैं। इस तरह libstd इसका उपयोग कर सकता है, लेकिन हम बाद में विवरण पर निर्णय ले सकते हैं।

मैंने संदर्भ खो दिया, यहाँ "ये" क्या है?

अभी, सौभाग्य से, सीटीएफई मिरी पॉइंटर मानों के साथ कुछ भी करने से इंकार कर देता है - अंकगणित, तुलना, सब कुछ त्रुटियां। यह गणना में वास्तव में उपयोग किए गए मूल्यों के आधार पर सीटीएफई समय पर किया गया एक चेक है, इसे यूनियनों द्वारा बाधित नहीं किया जा सकता है और वैसे भी कोड जो अंकगणित/तुलना करने के लिए आवश्यक होगा वह मौजूद नहीं है । इसलिए मुझे पूरा यकीन है कि हम ऊपर बताई गई गारंटी को पूरा करते हैं।

मैं समस्याओं की कल्पना कर सकता हूं अगर हमारे पास सीटीएफई एक सूचक मूल्य लौटाता है, लेकिन एक संकलन-समय-गणना सूचक मूल्य भी कहीं भी समझ में कैसे आता है? मुझे लगता है कि हम पहले से ही जांचते हैं कि मिरी जो भी गणना करता है उसमें पॉइंटर वैल्यू नहीं है क्योंकि हमें इसे बिट्स में बदलना है?

हम सावधानी से सीटीएफई मिरी में संचालन जोड़ सकते हैं, और वास्तव में हमें @eddyb के ऑफसेट_ऑफ [1] के लिए पॉइंटर घटाव की आवश्यकता है। वह कोड "पूर्ण मिरी" में मौजूद है, और यह केवल तभी सफल होता है जब दोनों पॉइंटर्स एक ही आवंटन के अंदर हों, जो उपरोक्त गारंटी को बनाए रखने के लिए पर्याप्त है। जो काम नहीं करेगा वह assert है जिसे @eddyb ने एक सुरक्षा उपाय के रूप में जोड़ा है।
हम पॉइंटर मानों पर बिट संचालन की अनुमति भी दे सकते हैं यदि संचालन केवल सूचक के संरेखित भाग को प्रभावित करता है, जो अभी भी नियतात्मक है और कोड वास्तव में "पूर्ण मिरी" में पहले से मौजूद है।

संपादित करें: [1] संदर्भ के लिए, मैं इस धागे में उनके मैक्रो का जिक्र कर रहा हूं जिसे हम लिंक नहीं कर सकते क्योंकि इसे ऑफ-टॉपिक के रूप में चिह्नित किया गया था, इसलिए यहां एक प्रति है:

macro_rules! offset_of {
    ($Struct:path, $field:ident) => ({
        // Using a separate function to minimize unhygienic hazards
        // (e.g. unsafety of #[repr(packed)] field borrows).
        // Uncomment `const` when `const fn`s can juggle pointers.
        /*const*/ fn offset() -> usize {
            let u = $crate::mem::MaybeUninit::<$Struct>::uninit();
            // Use pattern-matching to avoid accidentally going through Deref.
            let &$Struct { $field: ref f, .. } = unsafe { &*u.as_ptr() };
            let o = (f as *const _ as usize).wrapping_sub(&u as *const _ as usize);
            // Triple check that we are within `u` still.
            assert!((0..=$crate::mem::size_of_val(&u)).contains(&o));
            o
        }
        offset()
    })
}

EDIT2: दरअसल, उन्होंने इसे यहां पोस्ट भी किया था।

"ये" फ्लोट हैं -> बिट्स रूपांतरण और सूचक -> रूपांतरणों का उपयोग करें

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

तो रन टाइम पर तर्कों के साथ बुलाया गया एक फ़ंक्शन केवल गारंटीकृत शुद्धता है यदि यह वास्तव में समाप्त हो जाता है यदि समान तर्कों के साथ संकलन समय पर मूल्यांकन किया जाता है?

यह हमारे जीवन को एक लाख गुना आसान बना देगा, खासकर जब से मुझे नॉनडेटर्मिनिज्म को रोकने का कोई रास्ता नहीं दिख रहा है, या तो खामियों को छोड़े बिना या ब्रेकिंग-चेंज के तरीकों में अपंग करने वाले कॉन्स्ट एफएन को छोड़ दें।

तो रन टाइम पर तर्कों के साथ बुलाया गया एक फ़ंक्शन केवल गारंटीकृत शुद्धता है यदि यह वास्तव में समाप्त हो जाता है यदि समान तर्कों के साथ संकलन समय पर मूल्यांकन किया जाता है?

हां, मैं यही प्रस्ताव कर रहा हूं।

इसके बारे में कुछ और सोचकर (और जब मैं इसे लिख रहा था तो @ ओली-ओबीके का जवाब पढ़ रहा था), मुझे लगता है कि आप चाहते हैं कि "एक सुरक्षित const fn त्रुटि नहीं होगी" की तर्ज पर एक अतिरिक्त गारंटी है। वैध तर्कों के साथ बुलाए जाने पर CTFE समय (घबराहट के अलावा)। किसी प्रकार की "कॉन्स्ट सुरक्षा" गारंटी। रन-टाइम व्यवहार के साथ मेल खाने वाले सफल CTFE के बारे में मैंने ऊपर बताई गई गारंटी के साथ, यह गारंटी प्रदान करेगा कि एक सुरक्षित const fn रन-टाइम पर नियतात्मक होगा, क्योंकि यह सफल CTFE निष्पादन से मेल खाता है।

मैं सहमत हूं कि इसे प्राप्त करना एक कठिन गारंटी है। बेहतर या बदतर के लिए, जंग के पास विभिन्न सुरक्षित संचालन हैं जो सीटीएफई मिरी नियतत्ववाद को बनाए रखते हुए हमेशा सफलतापूर्वक निष्पादित करने की गारंटी नहीं दे सकते हैं, जैसे @Centril के oracle के संस्करण की तरह जो 0 होने के लिए कम से कम महत्वपूर्ण बाइट का परीक्षण करता है। परिप्रेक्ष्य से इस सेटिंग में CTFE के, " usize प्रकार के मान्य मान केवल PrimVal::Bytes हैं, जबकि PrimVal::Ptr की अनुमति नहीं दी जानी चाहिए [1]। यह ऐसा है जैसे हमारे पास कॉन्स संदर्भ में थोड़ा अलग प्रकार की प्रणाली है - मैं प्रस्ताव नहीं कर रहा हूं कि हम मिरी क्या करते हैं, मैं प्रस्ताव कर रहा हूं कि हम विभिन्न जंग प्रकारों को "मतलब" बदलते हैं जब एक const fn से जुड़ा होता है। इस प्रकार की प्रणाली गारंटी देगी कि सभी सुरक्षित अंकगणित और बिट संचालन सीटीएफई में गलत नहीं हो सकते हैं: सीटीएफई-वैध इनपुट के लिए, सीटीएफई में पूर्णांक घटाव कभी भी विफल नहीं हो सकता क्योंकि दोनों पक्ष PrimVal::Bytes हैं। बेशक, इस सेटिंग में ptr-to-int को एक असुरक्षित ऑपरेशन होना चाहिए क्योंकि इसके रिटर्न वैल्यू का प्रकार usize है लेकिन यह CTFE-मान्य usize नहीं है।

यदि यह एक गारंटी है जिसकी हम परवाह करते हैं, तो सीटीएफई कार्यों की जांच करते समय टाइप सिस्टम को और अधिक सख्त बनाना मेरे लिए अनुचित नहीं लगता है; आखिरकार, हम इसे और अधिक काम करने के लिए उपयोग करना चाहते हैं ("कॉन्स्ट सुरक्षा" की जांच)। मुझे लगता है कि यह बहुत मायने रखता है, फिर, const संदर्भ में ptr-to-int कास्ट unsafe घोषित करने के लिए, यह तर्क देते हुए कि इसकी आवश्यकता है क्योंकि const संदर्भ बनाता है अतिरिक्त गारंटी।

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

@eddyb के मैक्रो को एक असुरक्षित ब्लॉक की आवश्यकता होगी, लेकिन यह अभी भी उपयोग करने के लिए सुरक्षित होगा क्योंकि यह केवल इन "कॉन्स्ट असुरक्षित सुविधाओं" का उपयोग करता है (ptr-to-use और फिर परिणाम को घटाना, या केवल सूचक घटाव आंतरिक का उपयोग करना) सीधे) एक तरह से CTFE त्रुटि नहीं उठाने की गारंटी है।

इस तरह की एक प्रणाली की लागत यह होगी कि एक सुरक्षित उच्च-आदेश const fn को const fn को बंद करना होगा ताकि यह गारंटी दी जा सके कि क्लोजर को निष्पादित करना, "कॉन्स्ट सुरक्षा" का उल्लंघन नहीं करेगा। यह वास्तव में सुरक्षित const fn के बारे में उचित गारंटी प्राप्त करने की कीमत है।

[1] मैं यहां फ्लोट्स को पूरी तरह से नजरअंदाज कर रहा हूं क्योंकि मुझे इस बारे में ज्यादा जानकारी नहीं है कि गैर-निर्धारणवाद कहां पैदा होगा। क्या कोई फ़्लोटिंग पॉइंट कोड के लिए एक उदाहरण प्रदान कर सकता है जो रन-टाइम की तुलना में CTFE समय पर अलग व्यवहार करेगा? क्या यह पर्याप्त होगा उदाहरण के लिए मिरी एरर आउट करें, यदि फ्लोटिंग पॉइंट ऑपरेशन करते समय, ऑपरेंड में से एक सिग्नलिंग NaN है (पहली गारंटी प्राप्त करने के लिए, मेरी पिछली पोस्ट से एक), और यह कहने के लिए कि CTFE टाइप सिस्टम f32 / f64 ("कॉन्स्ट सुरक्षा" प्राप्त करने के लिए) प्रकार पर NaN को सिग्नलिंग की अनुमति नहीं देता है?

जो काम नहीं करेगा वह यह है कि @eddyb को एक सुरक्षा उपाय के रूप में जोड़ा गया है।

ज़रूर, लेकिन आप अभी के लिए assert!(condition); से [()][!condition as usize]; फिर से लिख सकते हैं।

ज़रूर, लेकिन आप फिर से लिख सकते हैं assert!(condition); से [()] [! स्थिति के रूप में उपयोग]; अभी के लिए।

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

संपादित करें: कोई बात नहीं, मुझे अभी एहसास हुआ कि assert ऑफ़सेट का परीक्षण करता है। तो वास्तव में यह CTFE समय पर कभी भी विफल नहीं हो सकता है क्योंकि यदि wrapping_sub करते समय पॉइंटर्स एक ही ब्लॉक में नहीं हैं, तो मिरी त्रुटि हो जाएगी।

// guess we can't have this as const fn
fn is_eq<T>(a: &T, b: &T) -> bool {
    a as *const _ == b as *const _
}

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

फ़ील्ड ऑफ़सेट प्राप्त करना नियतात्मक है। वर्चुअल पॉइंटर्स के साथ, यह नियतात्मक रहता है। वास्तविक संकेत के साथ, यह अभी भी नियतात्मक है।

एक सूचक के 14 वें बिट की समता प्राप्त करना नियतात्मक नहीं है। वर्चुअल पॉइंटर्स के साथ, यह नियतात्मक हो जाता है। वास्तविक संकेत के साथ, यह नियतात्मक नहीं है। यह ठीक है, क्योंकि एक संकलन-समय (एक नियतात्मक वातावरण) पर हो रहा है, जबकि दूसरा रनटाइम (एक गैर-नियतात्मक वातावरण) पर हो रहा है।

const fn उस वातावरण के रूप में नियतात्मक होना चाहिए जिसमें उनका उपयोग किया जा रहा है।

@ SonyEx2

// guess we can't have this as const fn

वास्तव में हम नहीं कर सकते। मुझे लगता है कि मैं कच्चे सूचक तुलना के एक संस्करण के साथ रह सकता हूं जो त्रुटियों से बाहर है यदि कोई सूचक वर्तमान में आवंटित वस्तु के भीतर होने के अर्थ में संदर्भित नहीं है (लेकिन यह वर्तमान में "पूर्ण मिरी" लागू नहीं है)। हालाँकि, यह अभी भी is_eq को "स्थिरांक सुरक्षित" नहीं बना देगा क्योंकि यदि T शून्य-आकार का है, तो यह किसी वस्तु के अंत से पहले एक को इंगित कर सकता है, भले ही हम केवल सुरक्षित कोड पर विचार करें।

सी ++ एक अनिश्चित (सोचें: नोडेटर्मिनिस्टिक) परिणाम उत्पन्न करने के लिए अंत में पॉइंटर्स की तुलना करने की अनुमति देता है। सी और सी ++ दोनों एक अनिश्चित परिणाम उत्पन्न करने के लिए एक लटकने वाले सूचक की तुलना करने की अनुमति देते हैं। यह स्पष्ट नहीं है कि एलएलवीएम क्या गारंटी देता है, लेकिन मैं उन गारंटी पर शर्त नहीं लगाऊंगा जो उन्हें सी/सी ++ (दोनों में से कमजोर, यदि वे भिन्न हैं) के लिए गारंटी देने के लिए अधिक हैं। यह एक समस्या है अगर हम सीटीएफई में सफलतापूर्वक निष्पादित होने वाली हर चीज के लिए रन-टाइम नियतत्ववाद की गारंटी देना चाहते हैं, जो मुझे लगता है कि हम करते हैं।

@ राल्फजंग

अंतर यह है कि क्या फ़ंक्शन निष्पादन भी पूरा करता है।

डेविल्स अधिवक्ता: एक मामले में "लौटना ⊥" एक ही है क्योंकि इसके अलग-अलग परिणाम हैं।

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

व्यक्तिगत रूप से मैं इसे आश्चर्यजनक व्यवहार के रूप में देखता हूं; आप इसे समझा सकते हैं, और मैं समझ सकता हूं (लेकिन मैं प्रतिनिधि नहीं हूं...), लेकिन यह मेरे अंतर्ज्ञान के अनुकूल नहीं है।

@ ओली-ओबीके

तो रन टाइम पर तर्कों के साथ बुलाया गया एक फ़ंक्शन केवल गारंटीकृत शुद्धता है यदि यह वास्तव में समाप्त हो जाता है यदि समान तर्कों के साथ संकलन समय पर मूल्यांकन किया जाता है?

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

@ राल्फजंग

यह गारंटी प्रदान करेगा कि रन-टाइम पर एक सुरक्षित const fn नियतात्मक होगा, क्योंकि यह सफल CTFE निष्पादन से मेल खाता है।

ठीक; तुमने मुझे खो दिया; मैं नहीं देखता कि आप दो परिसरों को देखते हुए इस "सुरक्षित कॉन्स्ट एफएन नियतात्मक है" गारंटी पर कैसे पहुंचे; क्या आप तर्क के बारे में विस्तार से बता सकते हैं?

यदि यह एक गारंटी है जिसकी हम परवाह करते हैं, तो सीटीएफई कार्यों की जांच करते समय टाइप सिस्टम को और अधिक सख्त बनाना मेरे लिए अनुचित नहीं लगता है; आखिरकार, हम इसे और अधिक काम करने के लिए उपयोग करना चाहते हैं ("कॉन्स्ट सुरक्षा" की जांच)। मुझे लगता है कि यह बहुत मायने रखता है, फिर, पीआरटी-टू-इंट को कॉन्स्ट संदर्भ में असुरक्षित घोषित करने के लिए, यह तर्क देते हुए कि इसकी आवश्यकता है क्योंकि कॉन्स संदर्भ अतिरिक्त गारंटी देता है।

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

ये पैराग्राफ मेरे कानों के लिए संगीत हैं! ❤️ ऐसा लगता है कि नियतिवाद ("शुद्धता") सुनिश्चित करता है? और ठीक वही बात है जो मेरे दिमाग में पहले थी। मुझे लगता है कि कॉन्स्ट सेफ्टी भी एक बढ़िया शब्द है!

भविष्य के संदर्भ के लिए, मैं इस गारंटी को "सीटीएफई सुदृढ़ता" कहता हूं: यदि सीटीएफई त्रुटि नहीं करता है, तो इसका व्यवहार रन-टाइम से मेल खाता है - दोनों अलग हो जाते हैं, या दोनों समान मूल्य के साथ समाप्त होते हैं। (मैं यहां उच्च-आदेश वापसी मूल्यों को पूरी तरह से अनदेखा कर रहा हूं।)

@सेंट्रिल

डेविल्स अधिवक्ता: एक मामले में "लौटना ⊥" एक ही है क्योंकि इसके अलग-अलग परिणाम हैं।

खैर, यह स्पष्ट रूप से परिभाषा की बात है। मुझे लगता है कि आप मेरे द्वारा वर्णित सीटीएफई सुदृढ़ता गारंटी को समझ गए हैं और आप सहमत हैं कि यह एक गारंटी है जो हम चाहते हैं; हम जो चाहते हैं वह चर्चा के लिए है :)

ठीक; तुमने मुझे खो दिया; मैं नहीं देखता कि आप दो परिसरों को देखते हुए इस "सुरक्षित कॉन्स्ट एफएन नियतात्मक है" गारंटी पर कैसे पहुंचे; क्या आप तर्क के बारे में विस्तार से बता सकते हैं?

मान लें कि हमारे पास foo(x) पर कुछ कॉल है जहां foo एक सुरक्षित कॉन्स फ़ंक्शन है और x एक कॉन्स्ट-वैध मान है (यानी, यह &y as *const _ as usize नहीं है ) तब हम जानते हैं कि foo(x) CTFE में बिना किसी त्रुटि के, const सुरक्षा द्वारा निष्पादित किया जाएगा। परिणामस्वरूप, CTFE सुदृढ़ता द्वारा, रन-टाइम पर foo(x) उसी तरह व्यवहार करेगा जैसे उसने CTFE में किया था।

अनिवार्य रूप से मुझे लगता है कि मैंने आपकी गारंटी को दो टुकड़ों में विघटित कर दिया है - एक यह सुनिश्चित करना कि एक सुरक्षित const fn कभी भी ऐसा कुछ करने का प्रयास नहीं करेगा जो CTFE का समर्थन नहीं करता है (जैसे stdin से पढ़ना, या यह निर्धारित करना कि पॉइंटर का कम से कम महत्वपूर्ण बाइट 0 है), और एक यह सुनिश्चित करता है कि जो कुछ भी सीटीएफई समर्थन करता है वह रनटाइम से मेल खाता है।

ये पैराग्राफ मेरे कानों के लिए संगीत हैं! दिल यह नियतत्ववाद ("शुद्धता") सुनिश्चित करता प्रतीत होता है? और ठीक वही बात है जो मेरे दिमाग में पहले थी। मुझे लगता है कि कॉन्स्ट सेफ्टी भी एक बढ़िया शब्द है!

खुशी है कि यह आपको पसंद है। :) इसका मतलब है कि मैं अंत में समझ गया कि हम यहाँ किस बारे में बात कर रहे हैं। "पवित्रता" का अर्थ कई अलग-अलग चीजें हो सकता है, जब इस शब्द का प्रयोग किया जाता है तो मैं अक्सर थोड़ा असहज महसूस करता हूं। और नियतत्ववाद कॉन्स्ट सुरक्षा के लिए पर्याप्त शर्त नहीं है, प्रासंगिक मानदंड यह है कि क्या सीटीएफई में निष्पादन एक त्रुटि उत्पन्न करता है। (निर्धारक गैर-कॉन्स्ट-सुरक्षित फ़ंक्शन का एक उदाहरण आपके orcale के मेरे संस्करण को 0 से गुणा करना है। असुरक्षित कोड का उपयोग करना भी ठीक नहीं है क्योंकि मिरी एक पॉइंटर के बाइट्स का निरीक्षण करते समय त्रुटि करेगा, भले ही बाइट्स अंततः कोई फर्क नहीं पड़ता। यह ऑपरेशन की तरह है जो पॉइंटर के कम से कम महत्वपूर्ण बाइट को निकालता है "कॉन्स्ट-यूबी" है और इसलिए असुरक्षित कॉन्स्ट कोड में भी इसकी अनुमति नहीं है।)

हां, एक सरणी तत्व के अंत से पहले एक सूचक अगले सरणी तत्व को इंगित करेगा, शायद। तो क्या है? यह वास्तव में nondeterministic नहीं है? संकलन-समय पर निर्धारक वैसे भी मायने रखता है। जहां तक ​​​​मुझे परवाह है, स्टैक थकावट के लिए रनटाइम मूल्यांकन segfault हो सकता है।

@ राल्फजंग

इस तरह की एक प्रणाली की लागत यह होगी कि एक सुरक्षित उच्च-आदेश const fn को यह सुनिश्चित करने में सक्षम होने के लिए एक कॉन्स्ट एफएन क्लोजर लेना चाहिए कि क्लोजर निष्पादित करना स्वयं "कॉन्स्ट सुरक्षा" का उल्लंघन नहीं करेगा। यह वास्तव में सुरक्षित const fn के बारे में उचित गारंटी प्राप्त करने की कीमत है।

मेरा मानना ​​​​है कि ?const की शुरुआत करके अधिकांश मौजूदा कोड को बदलने में सहायता के लिए इसे गंभीर रूप से कम किया जा सकता है, जहां आप उच्च ऑर्डर फ़ंक्शन लिख सकते हैं जिसका परिणाम const तक सीमित हो सकता है यदि और केवल तभी प्रदान किया गया फ़ंक्शन ?const fn(T) -> U है is_const(x : T) ; मतलब आपके पास है:

?const fn twice(fun: ?const fn(u8) -> u8) { fun(fun(42)) }

fn id_impure(x: u8) -> u8 { x }
const fn id_const(x: u8) -> u8 { x }
?const fn id_maybe_const(x: u8) -> u8 { x }

fn main() {
    let a = twice(id_impure); // OK!
    const b = twice(id_impure); // ERR!
    let c = twice(id_const); // OK!
    const d = twice(id_const); // OK!
    let e = twice(id_maybe_const); // OK!
    const f = twice(id_maybe_const); // OK!
}

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

@Centril इस बिंदु पर आप प्रभाव बहुरूपता के साथ एक प्रभाव प्रणाली विकसित कर रहे हैं। मुझे पता है कि यह हमेशा आपका गुप्त (?) एजेंडा था, बस आपको बता दें कि यह स्पष्ट रूप से स्पष्ट हो रहा है। ^^

@ राल्फजंग मैंने पिछले साल https://github.com/rust-lang/rfcs/pull/2237 पर पहले ही रहस्य का खुलासा कर दिया था, लेकिन मुझे इसे फिर से लिखना होगा;)
बहुत अधिक सार्वजनिक डोमेन अब ^,-

@ SonyEx2

हां, एक सरणी तत्व के अंत से पहले एक सूचक अगले सरणी तत्व को इंगित करेगा, शायद। तो क्या है? यह वास्तव में nondeterministic नहीं है? संकलन-समय पर निर्धारक वैसे भी मायने रखता है। जहां तक ​​​​मुझे परवाह है, स्टैक थकावट के लिए रनटाइम मूल्यांकन segfault हो सकता है।

समस्या निम्न जैसी स्थितियों में है (सी ++ में):

int x[2];
int y; // let's assume y is put right after the end of x in the stack frame
if (&x[0] + 2 == &y) {
  // ...
}

सी कंपाइलर उस तुलना को false से अनुकूलित करना चाहते हैं (और करते हैं!)। आखिरकार, एक सूचक x में इंगित करता है और एक y में इंगित करता है, इसलिए उनके लिए कभी भी बराबर होना संभव नहीं है।
सिवाय, ज़ाहिर है, कि पते मशीन पर बराबर हैं क्योंकि एक सूचक x के अंत में इंगित करता है, जो वही पता है (शुरुआत) y ! इसलिए, यदि आप कोड को इतना अस्पष्ट करते हैं कि संकलक को पता नहीं चलता है कि पते कहां से आते हैं, तो आप बता सकते हैं कि तुलना का मूल्यांकन true है। सी ++ मानक इसलिए दोनों परिणामों को गैर-निर्धारणात्मक रूप से होने की अनुमति देता है, दोनों अनुकूलन (जो false कहता है) और असेंबली के संकलन को उचित ठहराता है (जो true कहता है)। सी मानक इसकी अनुमति नहीं देता है, जिससे एलएलवीएम (और जीसीसी) गैर-अनुरूपता वाले कंपाइलर बन जाते हैं क्योंकि दोनों इस प्रकार के अनुकूलन करेंगे।

मैंने कॉन्स सेफ्टी, कॉन्स्ट साउंडनेस आदि के अपने विचारों का एक सारांश लिखा है जो इस थ्रेड में और/या आईआरसी पर संबंधित चर्चा में यहां आए हैं: https://www.ralfj.de/blog/2018/07/19/ const.html

यहां इस मुद्दे को सुलझाना थोड़ा मुश्किल हो गया है क्योंकि बहुत सी चीजों पर चर्चा की गई है। @ oli-obk ने कॉन्स्ट-ईवल चिंताओं के लिए मददगार रूप से एक रेपो बनाया, इसलिए विशिष्ट उप-मुद्दों पर चर्चा करने के लिए एक अच्छी जगह शायद https://github.com/rust-rfcs/const-eval का इश्यू ट्रैकर है।

@Centril ने एक न्यूनतम संस्करण को स्थिर करने का सुझाव दिया जो भविष्य के किसी भी एक्सटेंशन के अनुकूल हो:

• विशेषता सीमा के साथ कोई सामान्य तर्क नहीं
• कोई तर्क या वापसी प्रकार fn सूचक या dyn Trait प्रकार
  
  
  
  • तर्क प्रकार पर पुनरावर्ती रूप से जाँच की जाती है ताकि तर्कों के क्षेत्र भी इस प्रकार के न हों
  
  
• कोई असुरक्षित कोड नहीं है (क्योंकि हम नहीं जानते कि क्या वहां ऐसी चीजें हैं जो समस्याग्रस्त हैं)
  
  
  
  • मैं व्यक्तिगत रूप से सोचता हूं कि union s को छोड़कर ठीक है जो पहले से ही एक अतिरिक्त फीचर गेट के पीछे हैं, और कच्चे पॉइंटर डेरेफ्स (आमतौर पर किसी भी स्थिरांक में मना किया जाता है)। किसी भी अन्य असुरक्षित कोड को अन्य असुरक्षित कॉन्स fns या कॉन्स्ट इंट्रिनिक्स के माध्यम से जाने की आवश्यकता होती है, जिसके लिए अपनी स्वयं की चर्चा wrt स्थिरीकरण की आवश्यकता होती है।
  
  

(नाइट: मेरे सुझाव में fn पॉइंटर्स या dyn Trait के लिए const fn s के रिटर्न प्रकार पर एक पुनरावर्ती जांच भी शामिल है)

विशेषता सीमा के साथ कोई सामान्य तर्क नहीं

स्पष्ट करने के लिए, क्या ऐसा कुछ स्वीकार किया जाएगा या नहीं?

struct Mutex<T> where T: Send { /* .. */ }

impl<T> Mutex<T> where T: Send {
    pub const fn new(val: T) -> Self { /* .. */ }
}

बाउंड const fn ही हिस्सा नहीं है।

यह भी स्पष्ट करने के लिए: क्या उन चीजों को स्थिर करने और बाकी को फीचर गेट के पीछे छोड़ने का प्रस्ताव है या उन्हें स्थिर करने और बाकी को पूरी तरह से एक त्रुटि बनाने का प्रस्ताव है?

@ मार्क-इम बाकी एक फीचर गेट के पीछे रहेंगे।

@ oli-obk असुरक्षित कोड में क्या समस्या है? हम असुरक्षित const X : Ty = ... में अनुमति देते हैं, जिसमें सभी समान समस्याएं हैं। मुझे लगता है कि const fn निकायों की जांच बिल्कुल const निकायों की तरह की जानी चाहिए।

मुझे लगता है कि हम "अनकॉन्स्ट" ऑपरेशंस के आसपास रूढ़िवादी बने रहना चाहते हैं - ऐसे ऑपरेशन जो सुरक्षित हैं लेकिन कॉन्स्ट-सुरक्षित नहीं हैं (मूल रूप से कच्चे पॉइंटर्स पर कुछ भी) - लेकिन वे पहले से ही पूरी तरह से कॉन्स संदर्भ में अस्वीकृत हैं, है ना?

बाउंड कॉन्स्ट fn का ही हिस्सा नहीं है।

नहीं, उस प्रस्ताव के तहत इम्प्लांट ब्लॉक पर सीमा की भी अनुमति नहीं होगी

असुरक्षित कोड में समस्या क्या है?

जैसा कि मेरी टिप्पणी में बताया गया है, मुझे कोई समस्या नहीं दिख रही है। प्रत्येक कॉन्स असुरक्षित सुविधा/कार्य को वैसे भी अपने स्वयं के स्थिरीकरण से गुजरना पड़ता है।

@ राल्फजंग मुझे लगता है कि समस्या यह है कि " @Centril घबराया हुआ है कि हमने कुछ गलत किया है। वे पहले से ही पूरी तरह से कॉन्स्टेबल संदर्भ में अस्वीकृत हैं"। ;) लेकिन हमें किसी बिंदु पर unsafe { .. } को const fn में स्थिर करना होगा ताकि यदि आप सुनिश्चित हैं कि कोई समस्या नहीं है और हमने सभी गैर-कॉन्स्ट ऑपरेशन पकड़ लिए हैं तो चलिए इसे करते हैं?

इसके अलावा, अगर हम कुछ चूक गए हैं, तो हम पहले से ही खराब हैं क्योंकि लोग इसे const पर उपयोग कर सकते हैं।

मैं अभी भी कॉन्स्ट fn RFC रेपो के कॉन्स्ट सेफ्टी/प्रमोशन पार्ट्स में पीआर फिलिंग लिखने की योजना बना रहा हूं; अगर हम सब कुछ कवर करते हैं (और टेस्टकेस हैं) तो यह ध्यान से जांचने का समय होगा।

एक और चीज जो डिस्कॉर्ड पर आई वह है एफपी ऑपरेशंस: हम वर्तमान में गारंटी नहीं दे सकते कि वे वास्तविक हार्डवेयर से मेल खाएंगे। सीटीएफई आईईईई का बिल्कुल पालन करेगा, लेकिन एलएलवीएम/हार्डवेयर शायद नहीं।

यह const आइटम पर भी लागू होता है, लेकिन वे कभी भी रनटाइम-निष्पादित नहीं होंगे - जबकि const fn हो सकता है। इसलिए const fn में FP संचालन को स्थिर नहीं करना समझदारी है।

ओटीओएच, हम पहले से ही एफपी संचालन के परिणामों को बढ़ावा देते हैं? तो वहां हमारे पास पहले से ही रन-टाइम/संकलन-समय बेमेल स्थिर पर देखने योग्य है। क्या यह देखने के लिए एक गड्ढा चलाने लायक होगा कि क्या हम इसे पूर्ववत कर सकते हैं?

भविष्य के संदर्भ के लिए, निम्नलिखित लेख फ़्लोटिंग पॉइंट्स और नियतत्ववाद के संबंध में प्रासंगिक है:

• https://gafferongames.com/post/floating_point_determinism/

@ राल्फजंग

क्या यह देखने के लिए एक गड्ढा चलाने लायक होगा कि क्या हम इसे पूर्ववत कर सकते हैं?

अगर हम ऐसा कर पाते हैं तो मुझे आश्चर्य होगा, लेकिन यह कम से कम एक कोशिश के काबिल है। :)

@RalfJung इस धागे में आगे दिलचस्प इनपुट हो सकता है https://github.com/rust-lang/rust/issues/24111#issuecomment -386764565

मान लें कि हम कीवर्ड फॉर्म const fn रखना चाहते हैं, मुझे लगता है कि अब कुछ स्थिर करना, जो काफी सीमित है, एक बहुत अच्छा समाधान है (मैंने इसे पहले कैसे नहीं देखा?!)

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

सोम, अगस्त 20, 2018 दोपहर 1:44 बजे एडुआर्ड-मिहाई बर्टेस्कु <
सूचनाएं@github.com> ने लिखा:

यह मानते हुए कि हम कीवर्ड फॉर्म को स्थिर रखना चाहते हैं, मुझे लगता है कि स्थिर है
अब कुछ, जो काफी सीमित है, एक बहुत अच्छा समाधान है (कैसे
क्या मैंने इसे पहले नहीं देखा ?!)

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/rust-lang/rust/issues/24111#issuecomment-414403036 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAC3n80yVxIa3agsJP4wXZFkgyHVmAsjks5uSvWXgaJpZM4D66IA
.

@ est31 जैसा कि @ rkruppe ने पहले ही लिखा है, उन फ़्यूज़ को -ffast-math के बिना प्रदर्शन करना अवैध होगा - और मुझे लगता है कि LLVM इसे सही तरीके से संभालता है।

जो मुझे याद है, मूल अंकगणित भी वह सब समस्याग्रस्त नहीं है (32 बिट x86 को छोड़कर क्योंकि x87 ...), लेकिन अनुवांशिक कार्य हैं। और वे const fn नहीं हैं, है ना? तो मेरी आशा यह होगी कि अंत में हम इस संबंध में const आइटम, प्रचार और const fn के बीच समानता प्राप्त कर सकें।

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

जो मुझे याद है, मूल अंकगणित भी वह सब समस्याग्रस्त नहीं है (32 बिट x86 को छोड़कर क्योंकि x87 ...), लेकिन अनुवांशिक कार्य हैं।

ट्रान्सेंडैंटल फ़ंक्शंस का मतलब समस्या कैसे होगा?

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

@ est31 जबकि अधिकांश अनुवांशिक कार्य अंततः केवल आदिम पूर्णांक और फ्लोट संचालन से बना पुस्तकालय कोड हैं, ये कार्यान्वयन मानकीकृत नहीं हैं और व्यवहार में एक जंग कार्यक्रम अपने पूरे जीवनकाल में शायद तीन अलग-अलग कार्यान्वयन के साथ बातचीत कर सकता है, जिनमें से कुछ भी मेजबान या लक्ष्य से भिन्न होते हैं मंच:

• रनटाइम कार्यान्वयन है जो प्रोग्राम लक्ष्य पर उपयोग करता है (उदाहरण के लिए लक्ष्य प्लेटफ़ॉर्म libm, या कुछ परिस्थितियों में हार्डवेयर निर्देश)
• निरंतर फ़ोल्डर एलएलवीएम उपयोग करता है (जाहिर है यह सिर्फ मेजबान मंच सी libm है)
• इन परिचालनों के साथ MIRI जो कुछ भी करेगा (उदाहरण के लिए, rustc_apfloat में कुछ, या एक जंग कार्यान्वयन की व्याख्या करना जैसे कि https://github.com/japaric/libm/)

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

@rfcbot रद्द करें

हम निकट भविष्य में पूर्ण मोंटी को स्थिर करने की संभावना नहीं रखते हैं।
इसके बजाय, मैं अधिक न्यूनतम उपसमुच्चय के लिए आम सहमति विकसित करना चाहता हूं (जैसा कि मोटे तौर पर https://github.com/rust-lang/rust/issues/24111#issuecomment-414310119 में उल्लिखित है) कि हम उम्मीद करते हैं कि निकट अवधि में स्थिर हो सकते हैं .
यह सबसेट #53555 में ट्रैक किया गया है। आगे का विवरण वहाँ उपलब्ध है।

@Centril का प्रस्ताव रद्द कर दिया गया।

@rkruppe क्या अनुवांशिक कार्यों को llvm इंट्रिनिक्स में कम करने का कोई कारण है? क्या हम पूरी समस्या से बचने के लिए उन्हें जाने-माने, केवल जंग लगने वाले कार्यान्वयनों तक सीमित नहीं कर सकते हैं जिन्हें हम नियंत्रित करते हैं और जो सभी प्लेटफार्मों पर समान हैं?

क्या पारलौकिक कार्यों को एलएलवीएम इंट्रिनिक्स में कम करने का कोई कारण है?

संपूर्ण क्रॉस प्लेटफॉर्म लिबम को लागू नहीं करने की सादगी के अलावा, एलएलवीएम के ऑप्टिमाइज़र और कोडजेन में इंट्रिनिक्स का लाभ होता है जो एक साधारण लाइब्रेरी फ़ंक्शन को नहीं मिलेगा। स्पष्ट रूप से निरंतर तह (और संबंधित चीजें जैसे मूल्य सीमा विश्लेषण) इस संदर्भ में एक समस्या है लेकिन यह अन्यथा काफी उपयोगी है। बीजीय सर्वसमिकाएँ भी हैं (SimplifyLibCalls पास द्वारा लागू)। अंत में, कुछ फ़ंक्शन (ज्यादातर sqrt और इसके पारस्परिक, जो अनुवांशिक नहीं हैं लेकिन जो कुछ भी हैं) के पास विशेष कोड जनरेशन समर्थन है उदाहरण के लिए एसएसई के साथ x86 पर sqrtss उत्पन्न करें।

क्या हम पूरी समस्या से बचने के लिए उन्हें जाने-माने, केवल जंग लगने वाले कार्यान्वयनों तक सीमित नहीं कर सकते हैं जिन्हें हम नियंत्रित करते हैं और जो सभी प्लेटफार्मों पर समान हैं?

उपरोक्त सभी को अनदेखा करते हुए भी, यह आईएमओ का एक अच्छा विकल्प नहीं है। यदि लक्ष्य प्लेटफ़ॉर्म में C libm है, तो इसका उपयोग करना संभव होना चाहिए, या तो क्योंकि यह अधिक अनुकूलित है या ब्लोट से बचने के लिए है।

एलएलवीएम के अनुकूलक और कोडजन में इंट्रिनिक्स का लाभ है कि एक सामान्य पुस्तकालय समारोह नहीं मिलेगा।

मैंने सोचा है कि ऐसे अनुकूलन केवल तभी सक्षम किए जा रहे हैं जब तेज़ गणित चालू हो?

यदि लक्ष्य प्लेटफ़ॉर्म में C libm है, तो इसका उपयोग करना संभव होना चाहिए, या तो क्योंकि यह अधिक अनुकूलित है या ब्लोट से बचने के लिए है।

ज़रूर। संकलित बाइनरी या छोटे बायनेरिज़ की बेहतर गति की तरह अधिक मायने रखने वाली चीजों के पक्ष में इस अकादमिक संपत्ति - संदर्भात्मक पारदर्शिता - के व्यापार के लिए हमेशा एक विकल्प होना चाहिए। उदाहरण के libm प्लेटफ़ॉर्म का उपयोग करके या तेज़ गणित मोड चालू करके। या क्या आप सुझाव देते हैं कि हमें हमेशा के लिए तेज़ गणित मोड की अनुमति नहीं देनी चाहिए?

IMO हमें कॉन्स्टेबल संदर्भों में f32::sin() को अस्वीकार नहीं करना चाहिए, कम से कम तब नहीं जब हम + , - आदि की अनुमति दे रहे हों। इस तरह का प्रतिबंध लोगों को क्रेट बनाने और उपयोग करने के लिए मजबूर करेगा। जो कॉन्स्ट-संगत कार्यान्वयन प्रदान करते हैं।

मैंने सोचा है कि ऐसे अनुकूलन केवल तभी सक्षम किए जा रहे हैं जब तेज़ गणित चालू हो?

इन कार्यों का निरंतर मूल्यांकन और sqrtss के उत्सर्जन को -ffast-math के बिना उचित ठहराना आसान है, क्योंकि इसे सही ढंग से गोल किया जा सकता है।

या क्या आप सुझाव देते हैं कि हमें हमेशा के लिए तेज़ गणित मोड की अनुमति नहीं देनी चाहिए?

मैं कुछ भी सुझाव नहीं दे रहा हूं, और न ही मेरी राय (एटीएम) है कि क्या ऐसी संपत्ति की गारंटी दी जानी चाहिए। मैं केवल बाधाओं की रिपोर्ट कर रहा हूं।

कॉन्स्ट fn संदर्भ में Vec के कारण ICE के लिए एक खुला मुद्दा नहीं मिल सका।

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2015&gist=508238a9f06fd85720307bf6cc227586

क्या मुझे इसके लिए एक नया मुद्दा खोलना चाहिए?

@Voultapher हाँ जो एक नए ICE की तरह दिखता है।

ठीक है #55063 खोला।

यदि कंपाइलर यह जांचने में सक्षम है कि क्या किसी फ़ंक्शन को कंपाइल-टाइम कॉन्स्टेक्स में कॉल किया जा सकता है, जब कोई उपयोगकर्ता इसे const fn के साथ एनोटेट करता है, तो क्यों न केवल सभी कार्यों पर स्वचालित रूप से चेक किया जाए? (ऑटो-ट्रेट्स के समान)? मैं किसी भी वास्तविक प्रतिकूल प्रभाव के बारे में नहीं सोच सकता, और स्पष्ट लाभ यह है कि हमें त्रुटि-प्रवण मानव निर्णय पर निर्भर नहीं रहना है।

मुख्य नकारात्मक पक्ष यह है कि यह एक सार्वजनिक विवरण बन जाता है, इसलिए एक कार्यान्वयन
एक फ़ंक्शन में परिवर्तन जो कि कॉन्स्टेबल नहीं है, अब टूट रहा है।

साथ ही हमें मानवीय निर्णय पर निर्भर रहने की आवश्यकता नहीं है। हमारे पास एक क्लिपी लिंट हो सकता है जो हमें बताता है कि एक अघोषित फ़ंक्शन कब हो सकता है const fn : https://github.com/rust-lang/rust-clippy/issues/2440

यह उसी तरह है जैसे हम स्थानीय चरों की परिवर्तनशीलता का अनुमान नहीं लगाते हैं, लेकिन इसके बजाय संकलक हमें बताता है कि mut को कहां जोड़ना या हटाना है।

@remexre const fn एक इंटरफ़ेस विनिर्देश के रूप में कार्य करता है। मैं इस सुविधा के छोटे विवरणों से बहुत परिचित नहीं हूं (और शायद यहां जो कुछ भी है वह पहले से ही सोचा गया है), लेकिन दो मामले जहां मैं संकलक के बारे में सोच सकता हूं कि जब कोई फ़ंक्शन गलत तरीके से const के रूप में एनोटेट किया जाता है तो यह है संकलन विफल करने के लिए यदि ऐसा फ़ंक्शन पैरामीटर के रूप में &mut लेता है या यदि यह अन्य गैर- const फ़ंक्शन को कॉल करता है। इसलिए यदि आप const fn के कार्यान्वयन को बदलते हैं और आप उन प्रतिबंधों को तोड़ते हैं, तो संकलक आपको रोक देगा। फिर आप गैर- const बिट्स को (ए) अलग फ़ंक्शन में लागू करना चुन सकते हैं या एपीआई को तोड़ सकते हैं यदि वह एक इच्छित परिवर्तन था।

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

क्या एक कॉन्स fn आउटपुट का उत्पादन करने में सक्षम होना चाहिए? &mut की अनुमति क्यों नहीं दी जानी चाहिए?

@aledomu मेरी टिप्पणी @AGaussman पर निर्देशित की गई थी; मैं उस मामले के बारे में बात कर रहा हूं जहां एक पुस्तकालय लेखक एक ऐसे फ़ंक्शन का खुलासा करता है जो "होने के लिए" नहीं है (जिसमें कॉन्स्ट-नेस एपीआई का हिस्सा बनने का इरादा नहीं है); यदि कॉन्स्ट का अनुमान लगाया जाना था, तो उक्त फ़ंक्शन को गैर-कॉन्स्ट बनाने के लिए यह एक ब्रेकिंग बदलाव होगा।

@ SonyEx2 const fn एक ऐसा फ़ंक्शन है जिसका संकलन समय पर मूल्यांकन किया जा सकता है, जो कि केवल किसी भी शुद्ध फ़ंक्शन के मामले में होता है।

@remexre अगर यह एपीआई का एक स्थिर हिस्सा नहीं है, तो बस इसे चिह्नित न करें।

अनुमान के लिए मैंने टिप्पणी की, इसलिए मैंने टोकरा डॉक्स पर कुछ चेतावनी की आवश्यकता का उल्लेख किया।

क्या फर्क पड़ता है? बिल्कुल कोई नहीं!

const fn add_1(x: &mut i32) { x += 1; }
let mut x = 0;
add_1(&mut x);
assert_eq!(x, 1);
x = 0;
add_1(&mut x);
assert_eq!(x, 1);

const fn added_1(x: i32) -> i32 { x + 1 }
let mut x = 0;
x = added_1(x);
assert_eq!(x, 1);
x = 0;
x = added_1(x);
assert_eq!(x, 1);

मैंने इसके लिए लक्षित मुद्दे दायर किए हैं:

• फ़्लोटिंग पॉइंट्स + कॉन्स्ट इवल: https://github.com/rust-lang/rust/issues/57241
• पैटर्न के साथ एकीकरण: https://github.com/rust-lang/rust/issues/57240

निम्नलिखित लक्षित मुद्दे पहले से मौजूद हैं:

• घबराहट: https://github.com/rust-lang/rust/issues/51999
• लूप्स: https://github.com/rust-lang/rust/issues/52000
• नियंत्रण प्रवाह: https://github.com/rust-lang/rust/issues/49146
• कच्चे पॉइंटर्स की तुलना करना: https://github.com/rust-lang/rust/issues/53020
• कच्चे पॉइंटर्स को संदर्भित करना: https://github.com/rust-lang/rust/issues/51911
• usize कास्ट करने के लिए रॉ पॉइंटर: https://github.com/rust-lang/rust/issues/51910
• संघ क्षेत्र का उपयोग: https://github.com/rust-lang/rust/issues/51909
• लंबे समय से चल रहे मूल्यांकन पर चेतावनी: https://github.com/rust-lang/rust/issues/49980
• लगातार प्रसार त्रुटियों का कारण नहीं: https://github.com/rust-lang/rust/issues/28238
• &mut T संदर्भ और उधार: https://github.com/rust-lang/rust/issues/57349

यदि अन्य क्षेत्र हैं, जिन पर पहले से ही अन्य मुद्दों का ध्यान नहीं गया है, तो उस पर wrt पर चर्चा करने की आवश्यकता है। const eval और const fn , मेरा सुझाव है कि लोग नए मुद्दे बनाएं (और उनमें cc me + @ oli-obk)।

यह इस मुद्दे की उपयोगिता को समाप्त करता है, जिसे इसके द्वारा बंद किया जाता है।

मेरे पास सभी विशिष्टताओं को ध्यान में नहीं है, लेकिन क्या मिरी द्वारा समर्थित बहुत कुछ नहीं है लेकिन अभी तक min_const_fn में सक्षम नहीं है? उदाहरण के लिए कच्चे पॉइंटर्स।

@SimonSapin हाँ, अच्छी पकड़। इसके लिए कुछ और मौजूदा मुद्दे हैं। मैंने टिप्पणी + समस्या का विवरण अपडेट कर दिया है। अगर ऐसा कुछ है जो कवर नहीं किया गया है जिस पर आप होते हैं, तो कृपया नए मुद्दे बनाएं।

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

जब मैं सर्वो में #![feature(const_fn)] हटाता हूं, तो त्रुटि संदेश हैं:

• trait bounds other than `Sized` on const fn parameters are unstable
• function pointers in const fn are unstable

(ये const fn s निजी क्षेत्रों वाले प्रकारों के लिए सभी तुच्छ कंस्ट्रक्टर हैं। पूर्व संदेश struct Guard<T: Clone + Copy> के कंस्ट्रक्टर पर है, भले ही Clone कंस्ट्रक्टर में उपयोग नहीं किया गया हो। उत्तरार्द्ध Option<fn()> (सरलीकृत) को None या Some(name_of_a_function_item) में प्रारंभ करने के लिए है।)

हालांकि, इस मुद्दे के विवरण में न तो लक्षण और न ही फ़ंक्शन पॉइंटर प्रकार का उल्लेख किया गया है।

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

@SimonSapin

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

इस मुद्दे में https://github.com/rust-lang/rust/issues/34511 का स्वाद है, जो कि ट्रैकिंग के मुद्दों की सबसे बड़ी गड़बड़ियों में से एक है। यह समस्या कुछ समय के लिए सभी के लिए निःशुल्क भी है इसलिए यह अभी मेटा-समस्या के रूप में कार्य नहीं करता है। ऐसे फ्री-फॉर-ऑल के लिए, कृपया इसके बजाय http://internals.rust-lang.org/ का उपयोग करें।

हालांकि, इस मुद्दे के विवरण में न तो लक्षण और न ही फ़ंक्शन पॉइंटर प्रकार का उल्लेख किया गया है।

मेरा मतलब यह नहीं है कि उपरोक्त के लिए हमारे पास केवल दो और विशिष्ट मुद्दे होने चाहिए।

मेरे विचार से ठीक यही किया जाना चाहिए। टी-लैंग ट्राइएज के नजरिए से, लक्षित और कार्रवाई योग्य मुद्दों का होना अनुकूल है।

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

यह मेरे लिए यह भी स्पष्ट नहीं है कि const_fn फीचर गेट का गठन भी क्या है या यह सब किसी बिंदु पर स्थिर हो जाएगा। मूल RFC से सीमा और फ़ंक्शन पॉइंटर्स के अलावा सब कुछ खुले मुद्दे हैं और फिर कुछ।

यह मेरे लिए यह भी स्पष्ट नहीं है कि फीचर गेट का निर्माण भी क्या होता है

यही कारण है कि हमें इसे तब तक बंद नहीं करना चाहिए जब तक हम इसे समझ नहीं लेते, आईएमओ।

हर चीज़

हालाँकि, क्या यह वास्तव में सब कुछ है?

संबंधित: https://github.com/rust-lang/rust/issues/57261

क्या किसी को पता है कि const_string_new फीचर का क्या हुआ? क्या इसके लिए कोई ट्रैकिंग समस्या है? अस्थिर पुस्तक यहाँ लिंक करती है।

@phansch ऐसा इसलिए है क्योंकि सभी rustc_const_unstable यहां इंगित करते हैं। (सीसी @ ओली-ओबीके क्या हम इसे ठीक कर सकते हैं?)

तब मुद्दा खुला होना चाहिए। एक उपयोगकर्ता के रूप में इंगित किया जाना अपमानजनक है
एक बंद मुद्दे के लिए।

बुध, जनवरी 9, 2019, 04:05 मज़्दाक फ़ारोख़ज़ाद < नोटिफ़िकेशन @github.com . पर
लिखा था:

@phansch https://github.com/phansch ऐसा इसलिए है क्योंकि सभी
rustc_const_unstable बिंदु यहाँ।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/rust-lang/rust/issues/24111#issuecomment-452622097 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAC3n7JhzsZZpizmWlp0Nww5bcfIqH2Vks5vBbC8gaJpZM4D66IA
.

@ दुर्का : हमेशा एक संभावित खिड़की होने जा रही है जहां रात में कुछ बंद हो जाता है और संकल्प अभी भी स्थिर नहीं हुआ है। यह कैसा अपमानजनक है?

मैं यहां टिप्पणी करने का विरोध कर रहा हूं, और हो सकता है कि हमें इस बातचीत को इंटर्नल पर एक सूत्र में ले जाना चाहिए (क्या पहले से ही एक है?) लेकिन...

इसे बंद करने के फैसले का मेरे लिए कोई मतलब नहीं है। यह एक ट्रैकिंग समस्या है, क्योंकि यह संकलक से त्रुटि संदेशों में दिखाई देता है, और यह अकेला नहीं है, कुछ और उदाहरणों के लिए इस पोस्ट को देखें: https://internals.rust-lang.org/t/psa-tracking-for-gated -भाषा-विशेषताएं/2887. मेरे लिए इस मुद्दे को बंद करना स्थिरता का तात्पर्य है, जो स्पष्ट रूप से अभी तक नहीं है।

मैं स्पष्ट रूप से इसे बंद करने के लिए एक तर्क नहीं देख सकता ... मुझे खुशी है कि अब अधिक लक्षित मुद्दा मौजूद है, इसलिए कार्यान्वयन आगे बढ़ सकता है, उम्मीद है कि नई चर्चा और फोकस के साथ, लेकिन मुझे संकलक को जोड़ने का एक स्पष्ट तरीका नहीं दिख रहा है उन लोगों के साथ संदेश।

दोबारा, अगर इसे आंतरिक पर एक थ्रेड की आवश्यकता है (या पहले से ही है) तो शायद इस बातचीत को वहां ले जाएं?

संपादित करें: या यह मुद्दा है कि किताब पुरानी है? RFC से उदाहरण की कोशिश कर रहा है (इसमें कुछ #[derive(...)] s गायब है) Rust rustc 1.31.1 पर त्रुटियों के बिना काम करता प्रतीत होता है। क्या अभी भी संकलक त्रुटि संदेश यहाँ इंगित कर रहा है? त्रुटियों को जोड़ने के लिए एक जगह होना अच्छा होगा जैसे:

error: only int, `bool` and `char` operations are stable in const fn

यदि हम उन्हें विशिष्ट मुद्दों से जोड़ना चाहते हैं जो संभवतः एक सुधार होगा।

ठीक है, तो इस मुद्दे के खुले रहने के लिए यहां कुछ मजबूत सबूत होने चाहिए। जहाँ तक मैं यह बता सकता हूँ:

https://github.com/rust-lang/rust/blob/6ecad338381cc3b8d56e2df22e5971a598eddd6c/src/libsyntax/feature_gate.rs#L194

एकमात्र active सुविधा है जो एक बंद मुद्दे की ओर इशारा करती है।

एक आदर्श दुनिया में मेरा मानना ​​​​है कि इस तरह की चर्चाओं को वास्तव में स्वचालित होना चाहिए, क्योंकि जैसा कि हमने पाया है, लोगों की अलग-अलग राय और विचार हैं कि चीजों को कैसे काम करना चाहिए। लेकिन यह वास्तव में इस धागे के लिए बातचीत नहीं है...

यदि हम उन्हें विशिष्ट मुद्दों से जोड़ना चाहते हैं जो संभवतः एक सुधार होगा।

हां, यह सही समाधान है, और @Centril ने पहले ही क्या सुझाव दिया है ।

प्रारंभिक टिप्पणी को लोगों को उन विशिष्ट मुद्दों पर पुनर्निर्देशित करने के लिए भी संपादित किया गया है जो यहां "विंडो" में आते हैं जिसका @ErichDonGubler उल्लेख करता है ।

https://github.com/rust-lang/rust/issues/57563 अब शेष अस्थिर स्थिरांक सुविधाओं को ट्रैक करने के लिए खोल दिया गया है।

कोई व्यक्ति इस मुद्दे के मुख्य भाग को यहां संपादित कर सकता है ताकि प्रमुखता से #57563 से लिंक किया जा सके?

@glaebhoerl किया :)

नमस्ते, मैं यहाँ इसलिए आया क्योंकि ncurses-rs को संकलित करते समय मुझे error[E0658]: const fn is unstable (see issue #24111) मिला। मुझे क्या करना चाहिए? जंग अपग्रेड करें? मुझे मिल गया है

$ cargo version
cargo 1.27.0
$ rustc --version
rustc 1.27.2

संपादित करें: brew uninstall rust किया और रस्टअप इंस्टाल निर्देशों का पालन किया, अब rustc --version rustc 1.33.0 (2aa4c46cf 2019-02-28) है और वह त्रुटि दूर हो गई।

हां, स्थिर पर const fn का उपयोग करने में सक्षम होने के लिए, आपको अपने कंपाइलर को अपडेट करना होगा।