@rfcbot fcp मर्ज

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

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

चिंताओं:

• कार्यान्वयन-कार्य-अवरुद्ध-स्थिरीकरण https://github.com/rust-lang/rust/issues/62149#issuecomment -517418610 द्वारा हल किया गया

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

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

(यह सुनिश्चित करने के लिए कि वे फिसले नहीं हैं, मौजूदा ब्लॉकर्स को उपरोक्त रिपोर्ट में पंजीकृत करें)

@rfcbot चिंता कार्यान्वयन-कार्य-अवरुद्ध-स्थिरीकरण

टीम के सदस्य ... ने इसे मर्ज करने का प्रस्ताव दिया है

कोई जीथब मुद्दे को कैसे मर्ज कर सकता है (पुल अनुरोध नहीं)?

@vi बॉट बस थोड़ा सा बेवकूफ है और यह जांच नहीं करता है कि यह कोई मुद्दा है या पीआर :) आप यहां "मर्ज" को "स्वीकार करें" से बदल सकते हैं।

वाह, व्यापक सारांश के लिए धन्यवाद! मैं केवल मूर्त रूप से अनुसरण कर रहा हूं, लेकिन मुझे पूरा विश्वास है कि आप हर चीज में शीर्ष पर हैं।

@rfcbot ने समीक्षा की

क्या स्थिरीकरण अवरोधकों में स्पष्ट रूप से "ट्राएज AsyncAwait-अस्पष्ट मुद्दों" को जोड़ना संभव हो सकता है (और/या इसके लिए एक चिंता दर्ज करें)?

मुझे https://github.com/rust-lang/rust/issues/60414 मिला है जो मुझे लगता है कि महत्वपूर्ण है (जाहिर है, यह मेरी बग है: पी), और कम से कम स्थिरीकरण से पहले इसे स्पष्ट रूप से स्थगित करना चाहते हैं :)

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

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

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

@newpavlov मैंने एसिंक ड्रॉप के साथ करना पूरी तरह से संभव है। ऐसा करने के लिए कुछ अलग मार्ग हैं, जैसे संसाधन पूलिंग का उपयोग करना जहां संसाधन प्राप्त करने के लिए संभावित रूप से पुराने संसाधनों पर कुछ सफाई कार्य समाप्त होने की प्रतीक्षा करनी पड़ती है। वर्तमान फ्यूचर्स एपीआई उत्पादन प्रणालियों में इन समस्याओं को प्रभावी ढंग से हल करने के लिए इस्तेमाल किया जा सकता है और किया जा सकता है।

हालाँकि, यह समस्या async/प्रतीक्षा के स्थिरीकरण के बारे में है, जो कि फ्यूचर्स API डिज़ाइन के लिए ऑर्थोगोनल है, जो पहले ही स्थिर हो चुका है। बेझिझक आगे के प्रश्न पूछें या फ्यूचर्स-आरएस रेपो पर चर्चा के लिए एक मुद्दा खोलें।

@ एक्लोग

क्या स्थिरीकरण अवरोधकों में स्पष्ट रूप से "ट्राएज AsyncAwait-अस्पष्ट मुद्दों" को जोड़ना संभव हो सकता है (और/या इसके लिए एक चिंता दर्ज करें)?

हाँ, यह कुछ ऐसा है जो हम हर हफ्ते कर रहे हैं। WRT वह विशिष्ट मुद्दा (#60414), मेरा मानना ​​है कि यह महत्वपूर्ण है और इसे ठीक होते देखना अच्छा लगेगा, लेकिन हम अभी तक यह तय नहीं कर पाए हैं कि इसे स्थिरीकरण को अवरुद्ध करना चाहिए या नहीं, खासकर जब से यह पहले से ही -> impl Trait फ़ंक्शन।

@cramertj धन्यवाद! मुझे लगता है कि #60414 का मुद्दा मूल रूप से "त्रुटि अब वास्तव में जल्दी उत्पन्न हो सकती है", जबकि -> impl Trait ऐसा लगता है कि किसी ने भी इसे पहले नोटिस नहीं किया था - फिर यह ठीक है अगर इसे वैसे भी स्थगित कर दिया जाता है, कुछ मुद्दे करने के लिए :) (Fwiw यह एक समारोह में प्राकृतिक कोड में पैदा हुई जहां मैं दोनों लौट होगा () एक ही स्थान पर और T::Assoc एक और पर जो IIRC मुझे इसे संकलित करने के लिए प्राप्त करने में असमर्थ बना दिया है, - #60414 खोलने के बाद से कोड की जाँच नहीं की है, हालाँकि, शायद मेरी याद गलत है)

@Ekleog हाँ यह समझ में आता है! मैं निश्चित रूप से देख सकता हूं कि यह दर्द क्यों होगा-- मैंने उस विशिष्ट मुद्दे में और अधिक गोता लगाने के लिए है ।

संपादित करें: कोई बात नहीं, मैं 1.38 लक्ष्य से चूक गया।

@cramertj

ऐसा करने के लिए कुछ अलग मार्ग हैं, जैसे संसाधन पूलिंग का उपयोग करना जहां संसाधन प्राप्त करने के लिए संभावित रूप से पुराने संसाधनों पर कुछ सफाई कार्य समाप्त होने की प्रतीक्षा करनी पड़ती है।

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

@ड्यूक

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

यह समस्या 1.38 को लक्षित करती है, विवरण की पहली पंक्ति देखें।

@huxi धन्यवाद, मुझे वह याद आया। मेरी टिप्पणी संपादित की।

@newpavlov

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

नहीं, जरूरी नहीं, लेकिन आइए इस चर्चा को एक अलग थ्रेड पर एक मुद्दे पर ले जाएं, क्योंकि यह एसिंक्स/प्रतीक्षा के स्थिरीकरण से संबंधित नहीं है।

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

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

मैं टेलर से सहमत हूं कि इस समस्या स्थान में एपीआई डिज़ाइन पर चर्चा करना विषय से दूर होगा, लेकिन मैं इन टिप्पणियों के एक विशिष्ट पहलू को संबोधित करना चाहता हूं (और सामान्य रूप से io_uring के आसपास यह चर्चा) जो एसिंक/स्थिरीकरण की प्रतीक्षा के लिए प्रासंगिक है: की समस्या समय।

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

सुझाव है कि हमें अपने अंतर्निहित वायदा मॉडल पर फिर से विचार करना चाहिए, ये सुझाव हैं कि हमें उस स्थिति में वापस लौटना चाहिए जहां हम 3 या 4 साल पहले थे, और उस बिंदु से शुरू करें। उच्च स्तरीय प्राइमेटिव के लिए ओवरहेड पेश किए बिना किस तरह का अमूर्त पूर्णता-आधारित आईओ मॉडल को कवर कर सकता है, जैसे हारून ने वर्णित किया है? हम उस मॉडल को एक सिंटैक्स में कैसे मैप करेंगे जो उपयोगकर्ताओं को "सामान्य जंग + मामूली एनोटेशन" लिखने देता है जिस तरह से async/प्रतीक्षा करता है? हम इसे अपने मेमोरी मॉडल में एकीकृत करने में कैसे सक्षम होंगे, जैसा कि हमने इन राज्य मशीनों के लिए पिन के साथ किया है? इन सवालों के जवाब देने की कोशिश इस धागे के लिए विषय से परे होगी; मुद्दा यह है कि उनका उत्तर देना और उत्तरों को सही साबित करना काम है। अब तक विभिन्न योगदानकर्ताओं के बीच एक ठोस दशक के श्रम-वर्षों को फिर से करना होगा।

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

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

एक दिलचस्प पहलू जो हम यहां स्थिर कर रहे हैं, वह यह है कि हम सुरक्षित कोड से सेल्फ-रेफरेंशियल स्ट्रक्चर उपलब्ध करा रहे हैं। यह जो दिलचस्प बनाता है वह यह है कि Pin<&mut SelfReferentialGenerator> , हमारे पास एक परिवर्तनीय संदर्भ है ( Pin में एक फ़ील्ड के रूप में संग्रहीत) पूरे जेनरेटर राज्य को इंगित करता है, और हमारे पास उस राज्य के अंदर एक सूचक है जो इंगित करता है राज्य के दूसरे हिस्से में। परिवर्तनीय संदर्भ के साथ वह आंतरिक सूचक उपनाम !

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

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

प्रतिलिपि https://github.com/rust-lang/unsafe-code-guidelines/issues/148

मेरे ज्ञान के लिए परिवर्तनीय संदर्भ, वास्तव में स्मृति के उस हिस्से तक पहुंचने के लिए उपयोग नहीं किया जाता है जो पॉइंटर-टू-अदर-फील्ड इंगित करता है।

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

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

वास्तव में। ऐसा Debug कार्यान्वयन, यदि यह स्व-संदर्भित फ़ील्ड को प्रिंट करता है, तो संभवतः जनरेटर के अंदर एमआईआर-स्तरीय संदर्भ-आधारित अनुकूलन को प्रतिबंधित करेगा।

अवरोधकों के बारे में अद्यतन:

दो उच्च स्तरीय अवरोधकों ने बहुत प्रगति की है और वास्तव में दोनों समाप्त हो सकते हैं (?) इसके बारे में @cramertj @tmandry और @nikomatsakis से अधिक जानकारी बहुत अच्छी होगी:

• मल्टीपल लाइफटाइम इश्यू #61775 . तक ठीक हो जाना चाहिए था
• आकार का मुद्दा अधिक अस्पष्ट है; करने के लिए हमेशा अधिक अनुकूलन होंगे, लेकिन मुझे लगता है कि स्पष्ट घातीय वृद्धि से बचने के कम लटके हुए फल ज्यादातर हल हो गए हैं?

यह दस्तावेज़ीकरण और परीक्षण को इस सुविधा को स्थिर करने में प्रमुख अवरोधक के रूप में छोड़ देता है। @Centril ने लगातार चिंता व्यक्त की है कि इस सुविधा का अच्छी तरह से परीक्षण या पॉलिश नहीं किया गया है; @Centril क्या कहीं भी आपने विशिष्ट चिंताओं की गणना की है जिन्हें इस सुविधा को स्थिरीकरण के लिए चलाने के लिए चेक किया जा सकता है?

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

आज तक हमारे पास बीटा कट होने तक 6 सप्ताह का समय है, तो मान लें कि हमारे पास 4 सप्ताह (1 अगस्त तक) हैं, यह सुनिश्चित करने के लिए कि हम 1.38 नहीं खिसकेंगे।

आकार का मुद्दा अधिक अस्पष्ट है; करने के लिए हमेशा अधिक अनुकूलन होंगे, लेकिन मुझे लगता है कि स्पष्ट घातीय वृद्धि से बचने के कम लटके हुए फल ज्यादातर हल हो गए हैं?

मैं ऐसा मानता हूं, और कुछ अन्य को भी हाल ही में बंद कर दिया गया था; लेकिन अन्य अवरुद्ध मुद्दे हैं ।

@Centril क्या कहीं भी आपने विशिष्ट चिंताओं की गणना की है जिन्हें इस सुविधा को स्थिरीकरण के लिए चलाने के लिए चेक किया जा सकता है?

उन चीजों की सूची के साथ एक ड्रॉपबॉक्स पेपर है जिसे हम परीक्षण करना चाहते थे और वहां https://github.com/rust-lang/rust/issues/62121 है। इसके अलावा मैं उन क्षेत्रों की फिर से समीक्षा करने की कोशिश करूंगा जो मुझे लगता है कि ASAP के तहत परीक्षण किया गया है। उस ने कहा, कुछ क्षेत्रों का अब बहुत अच्छी तरह से परीक्षण किया गया है।

कोई भी जो पुस्तक, संदर्भ, आदि में इन-ट्री दस्तावेज़ीकरण में सुधार पर ध्यान केंद्रित करना चाहता है, वह एक महान सेवा कर रहा होगा!

वास्तव में; मुझे संदर्भ के लिए पीआर की समीक्षा करने में खुशी होगी। साथ ही cc @ehuss.

मैं एमवीपी से async unsafe fn को अपने स्वयं के फीचर गेट में स्थानांतरित करना चाहूंगा क्योंकि मुझे लगता है कि ए) इसका बहुत कम उपयोग देखा गया है, बी) यह विशेष रूप से अच्छी तरह से परीक्षण नहीं किया गया है, सी) यह अजीब तरह से व्यवहार करता है क्योंकि .await बिंदु वह नहीं है जहां आप unsafe { ... } लिखते हैं और यह "लीक कार्यान्वयन पीओवी" से समझ में आता है लेकिन प्रभाव पीओवी से इतना अधिक नहीं है, डी) इसमें बहुत कम चर्चा हुई है और इसे आरएफसी में शामिल नहीं किया गया था। न ही यह रिपोर्ट, और ई) हमने इसे const fn और यह ठीक काम किया। (मैं फीचर गेटिंग पीआर लिख सकता हूं)

मैं async unsafe fn को अस्थिर करने के साथ ठीक हूं, हालांकि मुझे संदेह है कि हम वर्तमान की तुलना में एक अलग डिजाइन के साथ बंद कर रहे हैं। लेकिन हमें यह पता लगाने के लिए समय देना बुद्धिमानी है!

मैंने async unsafe fn को एक विशिष्ट फीचर गेट पर ले जाने के लिए https://github.com/rust-lang/rust/issues/62500 बनाया और इसे एक अवरोधक के रूप में सूचीबद्ध किया। मुझे लगता है कि हमें शायद एक उचित ट्रैकिंग समस्या भी बनानी चाहिए।

मुझे दृढ़ता से संदेह है कि हम async unsafe fn लिए एक अलग डिज़ाइन तक पहुंचेंगे और स्थिरीकरण के प्रारंभिक दौर में इसे शामिल नहीं करने के निर्णय से आश्चर्यचकित हूं। मैंने कई async fn s लिखे हैं जो असुरक्षित हैं और उन्हें async fn really_this_function_is_unsafe() या कुछ और बना देंगे, मुझे लगता है। यह एक बुनियादी अपेक्षा में एक प्रतिगमन की तरह लगता है कि रस्ट उपयोगकर्ताओं को उन कार्यों को परिभाषित करने में सक्षम होने के मामले में है जिन्हें कॉल करने के लिए unsafe { ... } आवश्यकता होती है। फिर भी एक और फीचर गेट इस धारणा में योगदान देगा कि async / await अधूरा है।

@cramertj ऐसा लगता है जैसे हमें चर्चा करनी चाहिए! मैंने इसके लिए एक ज़ूलिप विषय बनाया है , ताकि इस ट्रैकिंग समस्या को बहुत अधिक लोड होने से बचाने की कोशिश की जा सके।

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

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

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

@cramertj (अनुस्मारक: मैं एसिंक /प्रतीक्षा के स्थिरीकरण में देरी के लिए तर्क की तरह लगता है, न कि उचित प्रयोग और विचार के बिना async unsafe को स्थिर करने के लिए।

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

[साइड नोट जो वास्तव में यहां चर्चा के लायक नहीं है: "फिर भी एक और फीचर गेट इस धारणा में योगदान देगा कि एसिंक/प्रतीक्षा अधूरा है", मुझे एसिंक/प्रतीक्षा का उपयोग करने के हर कुछ घंटों में एक बग मिला है, जो कुछ लोगों द्वारा फैलता है उन्हें ठीक करने के लिए rustc टीम द्वारा वैध रूप से महीनों की आवश्यकता होती है, और यही वह चीज़ है जो मुझे कहती है कि यह अधूरा है। पिछले एक को कुछ दिन पहले तय किया गया था, और मैं वास्तव में उम्मीद कर रहा हूं कि जब मैं अपने कोड को एक नए रस्टसी के साथ संकलित करने के लिए फिर से प्रयास करूंगा, तो मैं दूसरे को उजागर नहीं करूंगा, लेकिन…]

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

नहीं, यह उसके लिए कोई तर्क नहीं है। मेरा मानना ​​है कि async unsafe तैयार है, और इसके लिए किसी अन्य डिजाइन की कल्पना नहीं कर सकता। मेरा मानना ​​है कि इस प्रारंभिक रिलीज में इसे शामिल न करने के केवल नकारात्मक परिणाम हैं। मुझे विश्वास नहीं है कि async / await में देरी करने से, न ही async unsafe विशेष रूप से, बेहतर परिणाम देगा।

इसके लिए किसी अन्य डिजाइन की कल्पना नहीं कर सकता

एक वैकल्पिक डिज़ाइन, हालांकि निश्चित रूप से जटिल एक्सटेंशन की आवश्यकता होती है: async unsafe fn unsafe से .await , न कि call() । इसके पीछे तर्क यह है कि _कुछ भी असुरक्षित नहीं किया जा सकता_ उस बिंदु पर जहां async fn को कॉल किया जाता है और impl Future बनाता है। वह सब कदम डेटा को एक संरचना में रखता है (वास्तव में, सभी async fn कॉल करने के लिए const हैं)। असुरक्षितता का वास्तविक बिंदु भविष्य को poll साथ आगे बढ़ा रहा है।

(इम्हो, यदि unsafe तत्काल है, तो unsafe async fn अधिक समझ में आता है, और यदि unsafe में देरी हो रही है, तो async unsafe fn अधिक समझ में आता है।)

बेशक, हम कभी नहीं कहने का एक तरीका मिलता है जैसे unsafe Future जहां के सभी तरीकों Future कॉल करने के लिए असुरक्षित है, तो "उत्थापन" कर रहे हैं unsafe के निर्माण के लिए impl Future , और उस unsafe का अनुबंध परिणामी भविष्य को सुरक्षित तरीके से उपयोग करने के लिए किया जा रहा है। लेकिन इसे unsafe async fn बिना केवल "डिसुगरिंग" करके मैन्युअल रूप से async ब्लॉक: unsafe fn os_stuff() -> impl Future { async { .. } } बिना भी लगभग तुच्छ रूप से किया जा सकता है।

इसके शीर्ष पर, हालांकि, एक सवाल है कि क्या वास्तव में अपरिवर्तनीय होने का कोई तरीका मौजूद है जिसे एक बार poll आईएनजी शुरू होने के बाद आयोजित करने की आवश्यकता होती है जिसे सृजन पर आयोजित करने की आवश्यकता नहीं होती है। रस्ट में यह एक सामान्य पैटर्न है कि आप एक सुरक्षित प्रकार (जैसे Vec::from_raw_parts ) के लिए unsafe कंस्ट्रक्टर का उपयोग करते हैं। लेकिन महत्वपूर्ण बात यह है कि निर्माण के बाद, _cannot_ प्रकार का दुरुपयोग किया जा सकता है; unsafe दायरा खत्म हो गया है। असुरक्षितता का यह दायरा रस्ट की गारंटी की कुंजी है। यदि आप एक unsafe async fn जो एक सुरक्षित impl Future को क्रेट करता है, तो इसे कैसे/कब मतदान किया जाता है, इसके लिए आवश्यकताओं के साथ, फिर इसे सुरक्षित कोड में पास करें, वह सुरक्षित कोड अचानक आपके असुरक्षित बाधा के अंदर है। और यह _बहुत_ होने की संभावना है जैसे ही आप इस भविष्य का तुरंत इंतजार करने के अलावा किसी अन्य तरीके से उपयोग करते हैं, क्योंकि यह संभवतः _some_ बाहरी संयोजक के माध्यम से जाएगा।

मुझे लगता है कि इसका TL; DR यह है कि निश्चित रूप से async unsafe fn कोने हैं जिन पर इसे स्थिर करने से पहले ठीक से चर्चा की जानी चाहिए, विशेष रूप से const Trait की दिशा में संभावित रूप से पेश किया जा रहा है (मेरे पास एक मसौदा ब्लॉग है किसी भी fn -मॉडिफाइंग कीवर्ड के साथ इसे "कमजोर 'प्रभाव' प्रणाली" के सामान्यीकरण के बारे में पोस्ट करें)। हालांकि, unsafe async fn वास्तव में स्थिर होने के लिए unsafe के "आदेश"/"स्थिति" के बारे में पर्याप्त स्पष्ट हो सकता है।

मेरा मानना ​​​​है कि एक प्रभाव-आधारित unsafe Future विशेषता न केवल उस चीज़ की पहुंच से बाहर है जिसे हम आज भाषा या संकलक में व्यक्त करना जानते हैं, बल्कि यह कि अतिरिक्त प्रभाव के कारण यह अंततः एक बदतर डिज़ाइन होगा- बहुरूपता कि इसके लिए संयोजकों की आवश्यकता होगी।

उस बिंदु पर असुरक्षित कुछ भी नहीं किया जा सकता है जहां async fn कहा जाता है और impl Future बनाता है। वह सब कदम डेटा को एक संरचना में रखता है (वास्तव में, सभी async fn कॉल करने के लिए स्थिर हैं)। असुरक्षितता का वास्तविक बिंदु भविष्य को मतदान के साथ आगे बढ़ा रहा है।

यह सच है कि चूंकि async fn .await एड होने से पहले किसी भी उपयोगकर्ता कोड को नहीं चला सकता है, .await को कॉल किए जाने तक देरी हो सकती है। हालांकि, मुझे लगता है कि यूबी के बिंदु और unsafe ty के बिंदु के बीच एक महत्वपूर्ण अंतर है। unsafe ty का वास्तविक बिंदु वह है जहां एक एपीआई लेखक यह निर्णय लेता है कि उपयोगकर्ता को यह वादा करने की आवश्यकता है कि गैर-सांख्यिकीय-सत्यापन योग्य इनवेरिएंट का एक सेट पूरा हो गया है, भले ही उन इनवेरिएंट के उल्लंघन का परिणाम यूबी का कारण नहीं होगा। बाद में किसी अन्य सुरक्षित कोड में। इसका एक सामान्य उदाहरण एक unsafe फ़ंक्शन है जो एक मूल्य बनाने के लिए है जो एक विशेषता को सुरक्षित तरीकों से लागू करता है (वास्तव में यह क्या है)। मैंने देखा है कि यह सुनिश्चित करने के लिए उपयोग किया जाता है कि उदाहरण के लिए Visitor -ट्रेट-कार्यान्वयन प्रकार जिनके कार्यान्वयन unsafe इनवेरिएंट पर निर्भर करते हैं, प्रकार का निर्माण करने के लिए unsafe आवश्यकता के द्वारा अच्छी तरह से उपयोग किया जा सकता है। अन्य उदाहरणों में slice::from_raw_parts जैसी चीजें शामिल हैं, जो स्वयं यूबी का कारण नहीं बनेगी (वैधता अपरिवर्तनीय टाइप करें), लेकिन परिणामी स्लाइस तक पहुंच होगी।

मुझे विश्वास नहीं है कि async unsafe fn एक अद्वितीय या दिलचस्प मामले का प्रतिनिधित्व करता है-- यह unsafe आवश्यकता के द्वारा एक सुरक्षित इंटरफ़ेस के पीछे unsafe व्यवहार करने के लिए एक अच्छी तरह से स्थापित पैटर्न का पालन करता है। निर्माता।

@cramertj तथ्य यह है कि आप इसके लिए तर्क भी दे रहे हैं (और मैं सुझाव नहीं दे रहा हूं कि मुझे लगता है कि वर्तमान समाधान एक बुरा है, या मेरे पास एक बेहतर विचार है) का अर्थ है, मेरे लिए, यह बहस होनी चाहिए एक जंग की परवाह करने वाले लोगों को जगह दें: RFC रिपॉजिटरी।

एक अनुस्मारक के रूप में, इसके रीडमी से एक उद्धरण:

आपको इस प्रक्रिया का पालन करना होगा यदि [...] :

• भाषा में कोई भी अर्थपूर्ण या वाक्यात्मक परिवर्तन जो बगफिक्स नहीं है।
• [... और गैर-उद्धृत सामान भी]

मैं यह नहीं कह रहा हूं कि मौजूदा डिजाइन में कोई बदलाव होगा। दरअसल, इसके बारे में कुछ मिनट सोचने से मुझे लगता है कि यह संभवतः सबसे अच्छा डिज़ाइन है जिसके बारे में मैं सोच सकता था। लेकिन प्रक्रिया वह है जो हमें अपने विश्वासों को जंग के लिए खतरा बनने से बचने की अनुमति देती है, और हम कई लोगों के ज्ञान को याद कर रहे हैं जो RFC रिपॉजिटरी का पालन करते हैं, लेकिन यहां प्रक्रिया का पालन न करके हर एक मुद्दे को नहीं पढ़ते हैं।

कभी-कभी प्रक्रिया का पालन न करने का अर्थ हो सकता है। यहाँ मैं कोई अत्यावश्यकता नहीं देख सकता हूँ कि इस प्रक्रिया की अनदेखी करने के लिए कुछ 2 सप्ताह से बचने के लिए वारंट होगा FCP देरी।

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

मैं पुस्तक के लिए संदर्भ सामग्री पर पहला पास लिख रहा हूं। रास्ते में, मैंने देखा कि async-wait RFC का कहना है कि ? ऑपरेटर का व्यवहार अभी तक निर्धारित नहीं किया गया है। और फिर भी ऐसा लगता है कि यह एक एसिंक ब्लॉक ( खेल का मैदान ) में ठीक काम करता है। क्या हमें इसे एक अलग फीचर गेट पर ले जाना चाहिए? या यह किसी बिंदु पर हल किया गया था? मैंने इसे स्थिरीकरण रिपोर्ट में नहीं देखा, लेकिन शायद मैं चूक गया।

(मैंने यह प्रश्न ज़ूलिप पर भी पूछा था और मैं वहां प्रतिक्रियाओं को प्राथमिकता

हां, return , break , continue et के व्यवहार के साथ इस पर चर्चा और समाधान किया गया। अल. जो सभी "एकमात्र संभव काम" करते हैं और एक बंद के अंदर व्यवहार करते हैं।

let f = unsafe { || {...} }; भी कॉल करने के लिए सुरक्षित है और IIRC यह unsafe को क्लोजर के अंदर ले जाने के बराबर है।
unsafe fn foo() -> impl Fn() { || {...} } लिए वही बात।

यह, मेरे लिए, " unsafe दायरे को छोड़ने के बाद असुरक्षित चीज होती है" के लिए पर्याप्त उदाहरण है।

यही हाल अन्य जगहों का भी है। जैसा कि पहले बताया गया है, unsafe हमेशा वह नहीं होता जहां संभावित UB होगा। उदाहरण:

    let mut vec: Vec<u32> = Vec::new();

    unsafe { vec.set_len(100); }      // <- unsafe

    let val = vec.get(5).unwrap();     // <- UB
    println!("{}", val);

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

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

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

async unsafe fn

एसिंक असुरक्षित एफएनएस एसिंक फ़ंक्शन हैं जिन्हें केवल असुरक्षित ब्लॉक के अंदर ही बुलाया जा सकता है। उनके शरीर के अंदर एक असुरक्षित दायरे के रूप में माना जाता है। प्राथमिक वैकल्पिक डिज़ाइन कॉल करने के बजाय async असुरक्षित fns को प्रतीक्षा के लिए असुरक्षित बनाना होगा। उस डिज़ाइन को पसंद करने के कई ठोस कारण हैं जिसमें वे कॉल करने के लिए असुरक्षित हैं:

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

@rfcbot ने लैंग से पूछा "क्या हम async असुरक्षित fn को async fn के रूप में स्थिर करना स्वीकार करते हैं जो कॉल करने के लिए असुरक्षित है?"

मुझे नहीं पता कि rfcbot के साथ मतदान कैसे करना है, लेकिन मैंने इसे कम से कम नामांकित किया है।

टीम के सदस्य @withboats ने टीमों से पूछा है: टी-लैंग, इस पर आम सहमति के लिए:

"क्या हम एसिंक्स असुरक्षित एफएन को एसिंक्स एफएन के रूप में स्थिर करना स्वीकार करते हैं जो कॉल करने के लिए असुरक्षित है?"

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

@ नावों के बिना

मैं असुरक्षित async fns के इस मुद्दे के आसपास एक संरचित आम सहमति बिंदु पर एक स्टैब लेना चाहता हूं, इसलिए यह एक सर्वेक्षण के साथ एक सारांश पोस्ट है।

अद्यतित करने के लिए धन्यवाद। चर्चा ने मुझे आश्वस्त किया है कि async unsafe fn जैसा कि यह आज रात में काम करता है, सही व्यवहार करता है। (शायद कुछ परीक्षणों को जोड़ा जाना चाहिए क्योंकि यह विरल लग रहा था।) साथ ही, क्या आप कृपया अपनी रिपोर्ट के कुछ हिस्सों के साथ शीर्ष पर रिपोर्ट में संशोधन कर सकते हैं + async unsafe fn व्यवहार करता है इसका विवरण?

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

जैसा कि कोई बहुत ध्यान नहीं दे रहा है, मैं सहमत हूं और सोचता हूं कि यहां समाधान अच्छा दस्तावेज है।

मैं यहां निशान से बाहर हो सकता हूं, लेकिन यह देखते हुए

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

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

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

struct UnsafeOutput<T>(T);
impl<T> UnsafeOutput<T> {
    unsafe fn unwrap(self) -> T { self.0 }
}

यह देखते हुए कि unsafe नेस इस "शुरुआती असुरक्षित" में async नेस से पहले है, मुझे संशोधक ऑर्डर unsafe async fn से async unsafe fn unsafe async fn होने से बहुत खुशी होगी async unsafe fn , क्योंकि unsafe (async fn) उस व्यवहार पर async (unsafe fn) तुलना में अधिक स्पष्ट रूप से मानचित्र करता है।

मैं या तो खुशी-खुशी स्वीकार करूंगा, लेकिन मुझे दृढ़ता से लगता है कि यहां प्रदर्शित रैपिंग ऑर्डर में बाहर की तरफ unsafe , और संशोधक का क्रम इसे स्पष्ट करने में मदद कर सकता है। ( unsafe async fn का संशोधक है, न कि async का संशोधक unsafe fn ।)

मैं या तो खुशी-खुशी स्वीकार करूंगा, लेकिन मुझे दृढ़ता से लगता है कि यहां उजागर किए गए रैपिंग ऑर्डर में बाहर की तरफ unsafe , और संशोधक का क्रम इसे स्पष्ट करने में मदद कर सकता है। ( unsafe करने के लिए संशोधक है async fn , नहीं async करने के लिए आपरिवर्तक unsafe fn ।)

मैं आपके अंतिम संक्षिप्त बिंदु तक आपके साथ था। @withboats 'लेखन मेरे लिए यह बहुत स्पष्ट करता है कि, यदि कॉल साइट पर असुरक्षितता से निपटा जाता है, तो आपके पास वास्तव में एक unsafe fn (जिसे async संदर्भ में कहा जाता है)।

मैं कहूंगा कि हम बाइकशेड को पेंट करते हैं async unsafe fn ।

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

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

एफडब्ल्यूआईडब्ल्यू मैं एक ऐसी ही समस्या में भाग गया जिसका मैंने unsafe fn और फ़ंक्शन लक्षणों के अंदर बंद होने की बात आती है। मैं उम्मीद नहीं थी unsafe async fn वापस जाने के लिए एक Future एक तिजोरी के साथ poll विधि, लेकिन इसके बजाय एक वापस जाने के लिए UnsafeFuture एक साथ unsafe मतदान विधि। (*) तब हम .await को UnsafeFuture s पर भी काम कर सकते थे जब इसका उपयोग unsafe { } ब्लॉक के अंदर किया जाता है, लेकिन अन्यथा नहीं।

हमारे पास आज जो कुछ है, उसके संबंध में ये दो भविष्य के लक्षण एक बहुत बड़ा बदलाव होंगे, और वे शायद बहुत सारे कंपोजिबिलिटी मुद्दों को पेश करेंगे। तो विकल्प तलाशने के लिए जहाज शायद रवाना हो गया है। विशेष रूप से चूंकि यह अलग होगा कि Fn लक्षण आज कैसे काम करते हैं (उदाहरण के लिए हमारे पास UnsafeFn विशेषता या समान नहीं है, और RFC2585 में मेरा मुद्दा unsafe fn अंदर एक क्लोजर बनाना impls Fn() , यानी कॉल करने के लिए सुरक्षित है, भले ही यह क्लोजर असुरक्षित कार्यों को कॉल कर सकता है।

"असुरक्षित" भविष्य बनाना या बंद करना समस्या नहीं है, समस्या उन्हें यह साबित किए बिना बुला रही है कि ऐसा करना सुरक्षित है, खासकर जब उनके प्रकार यह नहीं कहते कि यह किया जाना चाहिए।

(*) हम सभी Future s के लिए UnsafeFuture का एक ब्लैंकेट इम्प्लांट प्रदान कर सकते हैं, और हम स्वयं को "अनरैप" करने के लिए UnsafeFuture एक unsafe विधि भी प्रदान कर सकते हैं एक के रूप में Future कि के लिए सुरक्षित है poll ।

यहाँ मेरे दो सेंट हैं:

• @cramertj की व्याख्या (https://github.com/rust-lang/rust/issues/62149#issuecomment-510166207) मुझे आश्वस्त करती है कि unsafe async फ़ंक्शन सही डिज़ाइन हैं।
• मैं unsafe और async . कीवर्ड के एक निश्चित क्रम को बहुत पसंद करता हूं
• मैं unsafe async fn ऑर्डर करना थोड़ा पसंद करता हूं क्योंकि ऑर्डरिंग अधिक तार्किक लगती है। "एक तेज इलेक्ट्रिक कार" बनाम "एक इलेक्ट्रिक फास्ट कार" के समान। मुख्य रूप से क्योंकि async fn एक fn लिए desugars। तो, यह समझ में आता है कि दो कीवर्ड एक दूसरे के बगल में हैं।

मुझे लगता है कि let f = unsafe { || { ... } } को f सुरक्षित बनाना चाहिए, एक UnsafeFn विशेषता को कभी भी पेश नहीं किया जाना चाहिए, और एक प्राथमिक .await आईएनजी और async unsafe fn होना चाहिए सुरक्षित। किसी भी UnsafeFuture को मजबूत औचित्य की आवश्यकता है!

यह सब इसलिए होता है क्योंकि unsafe स्पष्ट होना चाहिए, और जंग आपको सुरक्षित भूमि पर वापस ले जाना चाहिए। साथ ही इस टोकन द्वारा f के ... को _not_ एक असुरक्षित ब्लॉक होना चाहिए, https://github.com/rust-lang/rfcs/pull/2585 को अपनाया जाना चाहिए, और एक async unsafe fn सुरक्षित शरीर होना चाहिए।

मुझे लगता है कि यह अंतिम बिंदु काफी महत्वपूर्ण साबित हो सकता है। यह संभव है कि प्रत्येक async unsafe fn एक unsafe ब्लॉक को नियोजित करेगा, लेकिन इसी तरह अधिकांश को कुछ सुरक्षा विश्लेषण से लाभ होगा, और कई ध्वनि जटिल गलतियों के लिए पर्याप्त हैं।

विशेष रूप से क्लोजर के लिए कैप्चर करते समय हमें कभी भी बॉरो चेकर को बायपास नहीं करना चाहिए।

तो मेरी टिप्पणी यहाँ: https://github.com/rust-lang/rust/issues/62149#issuecomment -511116357 एक बहुत बुरा विचार है।

एक UnsafeFuture विशेषता के लिए कॉलर को भविष्य का चुनाव करने के लिए unsafe { } लिखने की आवश्यकता होगी, फिर भी कॉल करने वाले को यह पता नहीं है कि वहां कौन से दायित्वों को सिद्ध किया जाना चाहिए, उदाहरण के लिए, यदि आपको Box<dyn UnsafeFuture> unsafe { future.poll() } सुरक्षित है? सभी वायदा के लिए? आप नहीं जान सकते। तो यह पूरी तरह से बेकार होगा क्योंकि @rpjohnst ने एक समान UnsafeFn विशेषता के लिए कलह पर ध्यान दिया।

भविष्य के लिए हमेशा मतदान के लिए सुरक्षित रहने की आवश्यकता समझ में आती है, और भविष्य के निर्माण की प्रक्रिया जो मतदान के लिए सुरक्षित होनी चाहिए, असुरक्षित हो सकती है; मुझे लगता है कि async unsafe fn है। लेकिन उस स्थिति में, fn आइटम दस्तावेज कर सकता है जिसे बरकरार रखने की आवश्यकता है ताकि लौटा हुआ भविष्य मतदान के लिए सुरक्षित हो।

@rfcbot कार्यान्वयन-कार्य-अवरुद्ध-स्थिरीकरण

मेरी जानकारी में अभी भी 2 ज्ञात कार्यान्वयन अवरोधक हैं (https://github.com/rust-lang/rust/issues/61949, https://github.com/rust-lang/rust/issues/62517) और यह होगा कुछ परीक्षण जोड़ने के लिए अभी भी अच्छा है। मैं rfcbot को समय-समय पर हमारा अवरोधक नहीं बनाने के लिए अपनी चिंता का समाधान कर रहा हूं और फिर हम वास्तव में इसके बजाय सुधारों को रोक देंगे।

@rfcbot समाधान कार्यान्वयन-कार्य-अवरुद्ध-स्थिरीकरण

:घंटी: उपरोक्त समीक्षा के अनुसार, यह अब अपनी अंतिम टिप्पणी अवधि में प्रवेश कर रहा है । घंटी:

https://github.com/rust-lang/rust/pull/63209 में स्थिरीकरण पीआर दायर किया

उपरोक्त समीक्षा के अनुसार, विलय के स्वभाव के साथ अंतिम टिप्पणी अवधि अब पूरी हो गई है ।

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

आरएफसी का जल्द ही विलय किया जाएगा।

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

इसके अनुवर्ती के रूप में, @comex वास्तव में कुछ (सुरक्षित) async रस्ट कोड लिखने में कामयाब रहा