Rust: [स्थिरीकरण] पिन एपीआई

@rfcbot fcp मर्ज

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

• [x] @ किमुंडी
• [] @SimonSapin
• [x] @alexcrichton
• [x] @dtolnay
• [] @sfackler
• [x] @withoutboats

चिंताओं:

• box-pinnned-vs-box-pin (https://github.com/rust-lang/rust/issues/55766#issuecomment-443371976)
• सुधार-प्रलेखन (https://github.com/rust-lang/rust/issues/55766#issuecomment-443367737)
• https://github.com/rust-lang/rust/issues/55766#issuecomment -445074980 द्वारा निराकरण -नामकरण
• स्व-विधियाँ (https://github.com/rust-lang/rust/issues/55766#issuecomment-443368794)

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

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

यहाँ विस्तृत राइटअप के लिए धन्यवाद @withoutboats! मैंने Pin की विभिन्न गारंटियों द्वारा ऐतिहासिक रूप से भ्रमित किया है, और मुझे वर्तमान में API के बारे में कुछ प्रश्न मिले हैं, यहाँ सुरक्षा की गारंटी दी गई है। हालांकि मुझे लगा कि मैं इन चीजों को नीचे लिखने की कोशिश करूंगा।

हालांकि मैंने "क्या Unpin ?" मुझे लगता है कि क्या है और इसके चारों ओर विभिन्न गारंटी से उलझन में है। क्या आप फिर से कह सकते हैं कि T का मतलब क्या है और Unpin लागू नहीं करना है? इसके अलावा, अगर Unpin , इसे लागू करने के लिए एक सुरक्षित विशेषता है, तो ऐसा लगता है कि इसे आसानी से Pin<T> की असुरक्षित गारंटी को कमजोर करने के लिए इस्तेमाल किया जा सकता है, लेकिन मैं निश्चित रूप से कुछ याद कर रहा हूं

अगर मुझे यह सही मिला है, तो हर प्रकार जो स्वयं रेफरल नहीं है (यानी: जनरेटर नहीं) Unpin है

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

मैं कैसे Unpin को लागू करने के लिए सुरक्षित समझ रहा हूं, यह है कि इसे लागू करने से आप अपने द्वारा लिखे गए अन्य असुरक्षित कोड के लिए आवश्यक एक अपरिवर्तित उल्लंघन कर सकते हैं (महत्वपूर्ण रूप से, आप केवल इस असुरक्षित कोड को लिख सकते हैं, कोई बाहरी कोड इस बात पर निर्भर नहीं हो सकता है कि क्या आपने Unpin )। ऐसा कुछ भी नहीं है जो आप Pin के सुरक्षित API के साथ कर सकते हैं जो इस कारण से बेवफाई का कारण बनेगा कि आपने Unpin लागू किया है या नहीं। Pin कुछ Unpin लागू करेंगे। उपरोक्त "सेक्शन ऑन पिनिंग एंड सेफ्टी" सेक्शन 1 के अंक 1 से कवर किया गया है।

हम्म मैं अभी भी वास्तव में Unpin नहीं समझता हूं। मैं सबसे पहले यह समझने की कोशिश कर रहा हूं कि Unpin को लागू करने या न करने का क्या मतलब है।

सबसे पहले, यह जानना संभव है कि Unpin स्वचालित रूप से किस प्रकार लागू होते हैं! यह ऊपर बताया गया है कि सामान्य सूचक प्रकार (आर्क / आरसी / बॉक्स / संदर्भ) Unpin , लेकिन मुझे लगता है कि यह है? यदि यह एक ऑटो विशेषता है, तो क्या इसका मतलब है कि एक प्रकार MyType स्वचालित रूप से Unpin लागू होता है यदि इसमें केवल संकेत होते हैं? या कोई अन्य प्रकार स्वचालित रूप से Unpin लागू नहीं करता है?

मैं संक्षेप में बताने या बताने का प्रयास करता रहता हूं कि क्या Unpin गारंटी और ऐसा है, लेकिन मुझे ऐसा करना बहुत मुश्किल लग रहा है। क्या कोई फिर से दोहराकर मदद कर सकता है कि Unpin लागू करने का क्या अर्थ है और साथ ही Unpin लागू न करने का क्या मतलब है?

मुझे लगता है कि मैं Pin<P> की गारंटी को समझता हूं जहां आप P::Target के किसी भी इनलाइन सदस्यों से बाहर नहीं जा सकते, लेकिन क्या यह सही है?

@alexcrichton सवालों के लिए धन्यवाद, मुझे यकीन है कि

सबसे पहले, यह शायद यह जानने में मददगार है कि अनपिन किस प्रकार से स्वचालित रूप से लागू होता है!

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

सूचक प्रकारों के लिए स्पष्ट निहितार्थ Unpin भले ही उनके प्रकार के पैरामीटर न हों। इस टिप्पणी के अंत तक इसका कारण स्पष्ट रूप से स्पष्ट हो जाएगा।

क्या कोई फिर से दोहराकर मदद कर सकता है कि अनपिन को लागू करने का क्या मतलब है और साथ ही अनपिन को लागू न करने का क्या मतलब है?

यहाँ एपीआई एपीआई के मौलिक विचार की तरह है। सबसे पहले, एक पॉइंटर प्रकार P , Pin<P> P तरह काम करता है, जब तक कि Pin से संबंधित दो बुनियादी अपरिवर्तनीय असुरक्षित कोड हैं जिन्हें बनाए रखना है:

• आप unsafely एक मिलता है &mut P::Target से एक Pin<P> , आप ले नहीं करना चाहिए P::Target ।
• यदि आप Pin<P> निर्माण कर सकते हैं, तो यह गारंटी दी जानी चाहिए कि आप कभी भी उस डेटा को अनपिन किए गए पॉइंटर को प्राप्त नहीं कर पाएंगे जो पॉइंटर को चलाता है।

इस सब का निहितार्थ यह है कि यदि आप Pin<P> , तो P द्वारा इंगित किया गया मान फिर से नहीं जाएगा, जो कि हमें आत्म-संदर्भात्मक संरचना के साथ-साथ घुसपैठ के लिए आवश्यक गारंटी है संग्रह। लेकिन आप अपने प्रकार के लिए Unpin लागू करके इस गारंटी से बाहर निकल सकते हैं।

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

की तरह एक सूचक प्रकार आगे बढ़ते Rc<T> स्थानांतरित नहीं होता है T क्योंकि T एक सूचक के पीछे है। इसी तरह, एक पॉइंटर को Rc<T> ( Pin<Box<Rc<T>> ) में पिन करना वास्तव में T पिन नहीं करता है, यह केवल उस विशेष पॉइंटर को पिन करता है। यही कारण है कि कुछ भी जो एक पॉइंटर के पीछे अपने जेनेरिक को रखता है Unpin तब भी लागू कर सकता है जब उनके जेनेरिक नहीं करते हैं।

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

यह पिनिंग एपीआई के सबसे पेचीदा हिस्सों में से एक था, और हमें यह पहली बार में गलत लगा।

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

वास्तव में सेल्फ रेफरेंशियल टाइप को लागू करने के लिए असुरक्षित कोड की आवश्यकता होती है - व्यवहार में, किसी को भी केवल सेल्फ रेफरेंशियल टाइप्स की परवाह होती है, जो आपके लिए कंपाइलर जेनरेट करता है: जेनरेटर और एसिंक्स फंक्शन स्टेट मशीन। ये स्पष्ट रूप से कहते हैं कि वे Unpin लागू नहीं करते हैं और उनके पास Drop कार्यान्वयन नहीं है, इसलिए आप इन प्रकारों के लिए जानते हैं, जब आपके पास Pin<&mut T> , तो वे वास्तव में कभी भी एक परस्पर संदर्भ नहीं मिलता है, क्योंकि वे एक गुमनाम प्रकार हैं जिन्हें हम जानते हैं कि अनपिन या ड्रॉप लागू नहीं होता है।

एक बार जब आप इन गुमनाम प्रकारों में से एक की संरचना करते हैं तो समस्या सामने आती है, जैसे कि भविष्य के कॉम्बिनेटर। Pin<&mut Fuse<Fut>> से Pin<&mut Fut> क्रम में जाने के लिए, आपको "पिन प्रोजेक्शन" करना होगा। यह वह जगह है जहां आप मुसीबत में भाग सकते हैं: यदि आप किसी कॉम्बिनेटर के भविष्य के क्षेत्र में प्रोजेक्ट करते हैं, लेकिन फिर कॉम्बिनेटर के लिए ड्रॉप को लागू करें, तो आप उस फ़ील्ड से बाहर जा सकते हैं जिसे पिन किया जाना चाहिए।

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

तो, tl; dr: Drop मौजूद है, इसलिए Unpin सुरक्षित होना चाहिए। लेकिन यह पूरी बात को बर्बाद नहीं करता है, इसका मतलब यह है कि पिन प्रोजेक्शन unsafe और जो कोई भी प्रोजेक्ट को पिन करना चाहता है, उसे आक्रमणकारियों के एक सेट को बनाए रखना होगा।

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

क्या एसिंक्स स्टेट मशीन में Drop कार्यान्वयन नहीं होना चाहिए? ऐसी चीजें जो async फ़ंक्शन के "स्टैक" पर होती हैं (जो कि संभवतः स्टेट मशीन में फ़ील्ड्स के बराबर होती है), जब async फ़ंक्शन पूरा हो जाता है या रद्द हो जाता है, तो उसे नष्ट होने की आवश्यकता होती है। या यह अन्यथा होता है?

मुझे लगता है कि इस संदर्भ में क्या मायने रखता है कि क्या एक impl Drop for Foo {…} आइटम मौजूद है, जो &mut Foo के साथ कोड चलाएगा जो उदाहरण के लिए mem::replace का उपयोग "एक्सफ़िल्टर" कर सकता है और Foo स्थानांतरित कर सकता है

यह "ड्रॉप ग्लू" जैसा नहीं है, जिसे ptr::drop_in_place माध्यम से कहा जा सकता है। किसी दिए गए के लिए ड्रॉप गोंद Foo प्रकार फोन करेगा Drop::drop अगर यह लागू हो जाता है, तो रिकर्सिवली प्रत्येक क्षेत्र के लिए ड्रॉप गोंद कहते हैं। लेकिन उन पुनरावर्ती कॉलों में कभी भी &mut Foo शामिल नहीं होते हैं।

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

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

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

@Gankro ज़रूर, आप मुझे उसके लिए नीचे रख सकते हैं।

सभी को स्पष्टीकरण के लिए धन्यवाद!

मैं व्यक्तिगत रूप से async रस्ट और पिन एपीआई के लिए सुपर नया हूं, लेकिन मैंने पिछले दिनों (https://github.com/rust-lang-nursery/futures-rs/pull/1315) के दौरान इसके साथ थोड़ा सा खेला है। मैं async कोड में घुसपैठ संग्रह के लिए पिनिंग का फायदा उठाने की कोशिश की)।

प्रयोग के दौरान मुझे इन एपीआई के साथ कुछ चिंताएँ मिलीं:

• पूरी तरह से समझने के लिए पिनिंग की अवधारणा बहुत कठिन लगती है, भले ही कोई जानता हो कि स्थिर मेमोरी एड्रेस की आवश्यकता होती है। कुछ चुनौतियाँ जिनका मुझे सामना करना पड़ा:
  
  
  
  • त्रुटि संदेश जैसे:
    
    > impl core::future::future::Future+futures_core::future::FusedFuture भीतर, trait std::marker::Unpin std::marker::Pinned लिए लागू नहीं किया गया है
    
    यह एक बहुत पुनरावर्ती और विरोधाभासी लगता है (कुछ ऐसा क्यों किया जाना चाहिए जिसे पिन नहीं किया जाए?)
  
  
  • मैं अपनी विधि में परिवर्तनशील क्षेत्रों तक कैसे पहुंच सकता हूं जो एक पैरामीटर के रूप में एक पिन लेता है। यह खोज का एक सा ले लिया है, जिसने नए नियमों के बारे में सीखने ( Pin प्रक्षेपण), से तरीकों की नकल करने की कोशिश कर pin-utils , जब तक मुझे लगता है कि का उपयोग करता है 2 असुरक्षित तरीकों मैं क्या जरूरत करने के लिए एक समाधान के लिए आया था ।
  
  
  • मैं वास्तव में async पद्धति और select केस में अपने भविष्य का उपयोग कैसे कर सकता हूं। यह पता चला है कि मुझे फ्यूचर्स स्टैक के लिए pin_mut!() जरूरत है। जो वास्तव में एक स्टैक नहीं है, जो इसे भ्रमित करता है।
  
  
  • क्यों मेरी है drop() विधि अब फिर से लेने के &mut self , एक के बजाय Pin ।
  
  
  • कुल मिलाकर यह चीजों को संकलित करने की उम्मीद में असुरक्षित संबंधित एपीआई का उपयोग करते हुए बेतरतीब ढंग से महसूस करने का एक सा था, जो निश्चित रूप से आदर्श स्थिति नहीं होनी चाहिए। मुझे संदेह है कि अन्य लोग भी इसी तरह की चीजें करने की कोशिश कर सकते हैं।
  
  
• यह अवधारणा पूरे कोडबेस में बहुत कुछ फैलाती है, जो बहुत सारे लोगों को यह समझने के लिए मजबूर करता है कि Pin और Unpin वास्तव में क्या हैं। ऐसा लगता है कि कुछ विशेष उपयोग के मामलों के लिए कार्यान्वयन के विवरण का एक सा रिसाव है।
• पिन जीवनकाल से कुछ हद तक संबंधित है, लेकिन कुछ हद तक रूढ़िवादी भी है। मूल रूप से एक पिन हमें बताता है कि हम एक वस्तु को फिर से उसी पते के साथ देख सकते हैं जब तक drop() कहा जाता है। जो इसे वर्तमान क्षेत्र और 'static बीच किसी प्रकार का आभासी जीवनकाल देता है। ऐसा लगता है कि 2 अवधारणाएं हैं जो संबंधित हैं, लेकिन अभी भी पूरी तरह से अलग हैं। मुझे आश्चर्य हुआ कि क्या इसे 'pinned जैसी किसी चीज़ द्वारा मॉडलिंग किया जा सकता है।

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

एलेक्स Unpin टिप्पणी के बारे में: मैं धीरे-धीरे समझ रहा हूं कि क्या Unpin मतलब है, लेकिन मैं मानता हूं कि यह समझना मुश्किल है। शायद एक और नाम मदद करता है, लेकिन मैं अभी एक संक्षिप्त नहीं ढूँढ सकता। ThingsInsideDontBreakIfObjectGetsMoved , DoesntRequireStableAddress , PinDoesntMatter , आदि के साथ कुछ।

जो मुझे अभी तक पूरी तरह से समझ में नहीं आया है, वह &mut self Pin<&mut self> हो जाना सभी प्रकार के लिए सुरक्षित क्यों नहीं हो सकता है। यदि पिन का अर्थ केवल ऑब्जेक्ट का पता ही स्थिर होगा, तो यह सबसे विशिष्ट रस्ट प्रकारों के लिए सही होना चाहिए। ऐसा लगता है कि पिन में एकीकृत एक और चिंता का विषय है, जो यह है कि इसके अंदर स्वयं-संदर्भित प्रकार भी नहीं टूटते हैं। Pin होने के बाद उन लोगों के साथ छेड़छाड़ करना हमेशा असुरक्षित होता है। लेकिन मुझे लगता है कि ज्यादातर मामलों में वे कंपाइलर-जनरेट होंगे, और अनिश्चितता या यहां तक ​​कि कच्चे पॉइंटर्स भी ठीक होने चाहिए। मैन्युअल रूप से भविष्य के कॉम्बिनेटरों के लिए जो पिनड कॉल को उपक्षेत्रों में अग्रेषित करने की आवश्यकता है, जाहिर तौर पर उन लोगों को मतदान करने से पहले खेतों में पिन बनाने के लिए असुरक्षित कॉल करने की आवश्यकता होगी। लेकिन उस मामले में मैं उस जगह से संबंधित अनैतिकता को अधिक देखता हूं जहां यह वास्तव में मायने रखता है (क्या पिन अभी भी वैध है?) अन्य क्षेत्रों तक पहुंचने की तुलना में जिसके लिए यह बिल्कुल भी मायने नहीं रखता है।

एक और विचार यह था कि यदि कुछ सीमाएँ लागू की जाती हैं तो क्या यह एक सरल प्रणाली प्राप्त करना संभव है। उदाहरण के लिए, जिन चीजों की पिनिंग की आवश्यकता होती है, उनका उपयोग केवल एसिंक्स विधियों के अंदर किया जा सकता है और भविष्य के कॉम्बिनेटरों के साथ नहीं। हो सकता है कि यह Pin या Unpin से किसी को भी आसान बना सके। यह देखते हुए कि बहुत सारे कोड के लिए async / select / join सपोर्ट के साथ इंतजार करने के तरीके combinators के अनुकूल हो सकते हैं, यह सबसे अधिक नुकसान नहीं हो सकता है। लेकिन मैंने वास्तव में पर्याप्त विचार नहीं रखे हैं कि क्या यह वास्तव में मदद करता है।

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

माइनर नाइट wrt स्थिरीकरण रिपोर्ट:

fn get_unchecked_mut(self) -> &'a mut T

मुझे लगता है कि यह वास्तव में एक unsafe fn ?

@ Matthias247 आप सुरक्षित रूप से Pin<P<T>> से T & Un नहीं पा सकते हैं यदि T अनपिन नहीं है, तो फिर आप T को पिन से बाहर करने के लिए mem::swap कर सकते हैं, जो चीजों को पिन करने के उद्देश्य को हरा देगा।

एक चीज जो मुझे खुद को समझाने में परेशानी होती है, वह है जो फ्यूचर को मौलिक रूप से अन्य लक्षणों से अलग बनाती है जैसे कि पिन को अपने एपीआई का हिस्सा होना चाहिए। मेरा मतलब है, मुझे पता है कि यह सहज रूप से है क्योंकि async / प्रतीक्षा में पिनिंग की आवश्यकता होती है, लेकिन क्या यह विशेष रूप से फ्यूचर्स के बारे में कुछ कहता है, Iterators से अलग है?

क्या पोल और म्युट सेल्फ को ले सकता है और केवल Pin<P> प्रकारों या प्रकारों के लिए Future को कार्यान्वित कर सकता है जो Unpin हैं?

मैं अपनी विधि में परिवर्तनशील क्षेत्रों तक कैसे पहुंच सकता हूं जो एक पैरामीटर के रूप में एक पिन लेता है।

यह वास्तव में मुझे आश्चर्यचकित करता है कि क्या Pin पर गुम तरीकों की एक जोड़ी है,

impl<'a, T: ?Sized> Pin<&'a T> {
    fn map<U: Unpin, F: FnOnce(&T) -> &U>(self, f: F) -> Pin<&'a U>
}

impl<'a, T: ?Sized> Pin<&'a mut T> {
    fn map<U: Unpin, F: FnOnce(&mut T) -> &mut U>(self, f: F) -> Pin<&'a mut U>
}

इनका उपयोग pin_utils::unsafe_unpinned! मैक्रो में किया जा सकता है।

मैं _why_ वर्कआउट करने की कोशिश कर रहा हूं यह मैक्रो असुरक्षित होने का दावा करता है। यदि हम !Unpin और Unpin फ़ील्ड हैं, तो इस क्षेत्र में प्रोजेक्ट करना असुरक्षित क्यों होगा?

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

पिछली स्थिति को सुरक्षित बनाने के लिए Pinned पर मार्किंग के लिए एक रैपर बनाया जा सकता है, जो सामान्य रूप से Unpin किसी संरचना के !Unpin Pinned समग्र रूप में संरचना के लिए

pub struct MustPin<T: Unpin>(T, Pinned);

impl<T: Unpin> MustPin<T> {
    pub const fn new(t: T) -> Self { ... }
    pub fn get(self: Pin<&Self>) -> *const T { ... }
    pub fn get_mut(self: Pin<&mut Self>) -> *mut T { ... }
}

यह सब वर्तमान एपीआई के साथ पीछे की ओर संगत लगता है, यह futures-rs कॉम्बिनेटरों से कुछ असमानता को दूर कर सकता है (जैसे यह इस तरह के अतिरिक्त क्षेत्रों में सुरक्षित पहुंच देगा), लेकिन वर्तमान usecases के लिए आवश्यक नहीं है। कस्टम !Unpin प्रकार (जैसे घुसपैठ संग्रह) को लागू करने के लिए हम शायद कुछ एपीआई के साथ प्रयोग कर सकते हैं और बाद में इसे जोड़ सकते हैं।

@ Nemo157 उन नक्शा कार्यों क्योंकि मैं कर सकता है असुरक्षित हैं mem::swap पर &mut T समारोह एक लौटने से पहले मुझे गुजरता &mut U । (अच्छी तरह से परस्पर एक है, अपरिवर्तनीय असुरक्षित नहीं हो सकता है)

संपादित करें: इसके अलावा पिन-बर्तनों का मैक्रो अलग है, unsafe_unpinned doesnt का लक्ष्य प्रकार Unpin , इसका सिर्फ एक "अनपिन किया गया प्रक्षेपण" है - &mut Field एक प्रक्षेपण। !Unpin ।

एक चीज जो मुझे खुद को समझाने में परेशानी होती है, वह है जो फ्यूचर को मौलिक रूप से अन्य लक्षणों से अलग बनाती है जैसे कि पिन को अपने एपीआई का हिस्सा होना चाहिए। मेरा मतलब है, मुझे पता है कि यह सहज रूप से है क्योंकि async / प्रतीक्षा में पिनिंग की आवश्यकता होती है, लेकिन क्या यह विशेष रूप से फ्यूचर्स के बारे में कुछ कहता है, Iterators से अलग है?

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

एक और महत्वपूर्ण अंतर यह है कि Iterator और Future बीच कोड पैटर्न काफी अलग हैं। आप भविष्य में एक प्रतीक्षित बिंदु पर उधार लेने की इच्छा के बिना 10 मिनट तक नहीं जा सकते, यही कारण है कि वायदा 0.1 पर आप इन Arc सभी जगह दिखाई दे रहे हैं ताकि आप एक ही चर का उपयोग दो अलग-अलग में कर सकें and_then कॉल। लेकिन हम सभी पर स्व-रेफरेंशियल पुनरावृत्तियों को व्यक्त किए बिना बहुत दूर हो गए हैं, यह सिर्फ एक उपयोग के मामले के लिए महत्वपूर्ण नहीं है ।

उन नक्शा कार्यों असुरक्षित हैं क्योंकि मैं कर सकता है mem::swap पर &mut T समारोह एक लौटने से पहले मुझे गुजरता &mut U

आह, लानत है, उसके उस हिस्से के बारे में भूल गया: frowning:

fn as_mut(&mut self) -> Pin<&mut P::Target> fn in_ref (स्वयं) -> पिन <और 'a T> `

क्या उन्हें as_pinned_mut और into_pinned_ref कहा जाना चाहिए, ताकि वे उन तरीकों से भ्रमित न हों जो वास्तव में संदर्भ देते हैं?

स्टैम्प में अनपिन के उल्लेखनीय कार्यान्वयन:

हमारे पास impl<P> Unpin for Pin<P> {} । हमारे द्वारा उपयोग किए जाने वाले प्रकारों के लिए इसका कोई प्रभाव नहीं है और यह थोड़ा सुरक्षित लगता है?
कोई बात नहीं, आप अपनी सूची में है। ;)

गारंटी छोड़ दें

मुझे लगता है कि हमें स्थिरीकरण से पहले Drop गारंटी को संहिताबद्ध करना होगा, वरना बहुत देर हो जाएगी:

बिना ऑब्जेक्ट पर drop कॉल किए बिना किसी पिन की गई वस्तु ( Pin संदर्भ का लक्ष्य) को संग्रहीत करना अवैध है।

यहां "अमान्य" का अर्थ "डीललोकेशन" हो सकता है, लेकिन "पुनर्खरीद" भी हो सकता है: x Ok(foo) से Err(bar) बदलने पर, foo का संग्रहण अमान्य हो जाता है ।

इसका परिणाम यह होता है, उदाहरण के लिए, कि Pin<Box<T>> , Pin<Rc<T>> या Pin<Arc<T>> बिना पहले कॉल किए drop::<T> डील करना अवैध हो जाता है।

Deref , DerefMut

मैं अभी भी इस बारे में थोड़ा असहज महसूस करता हूं कि यह " Deref " का अर्थ "यह एक स्मार्ट पॉइंटर" कैसे है। हम "विरासत" के लिए Deref उपयोग अन्य चीजों के लिए भी करते हैं, जैसे। यह एक विरोधी पैटर्न हो सकता है, लेकिन यह अभी भी काफी सामान्य उपयोग में है और, स्पष्ट रूप से, यह उपयोगी है। : डी

मुझे लगता है कि यह एक ध्वनि मुद्दा नहीं है।

समझ Unpin

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

• पिनिंग पर एक औपचारिक रूप
• पिनिंग के साथ सुरक्षित घुसपैठ संग्रह

सुरक्षित पिन अनुमान

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

क्यों मेरी ड्रॉप () विधि अब फिर से और पिन के बजाय, स्वयं को ले जाती है।

खैर, drop() पुराना है - यह रुस्त 1.0 के बाद से मौजूद है - इसलिए हम इसे बदल नहीं सकते। हम इसे Pin<&mut Self> , और फिर Unpin प्रकार अपने &mut प्राप्त कर सकते हैं जैसे वे अभी करते हैं, लेकिन यह एक गैर-बैकवर्ड-संगत परिवर्तन है।

भविष्य के कॉम्बिनेटरों को सुरक्षित बनाने के लिए, हमें सुरक्षित पिन अनुमानों की आवश्यकता होगी, और इसके लिए हमें संकलक को बदलना होगा, यह एक पुस्तकालय में नहीं किया जा सकता है। हम इसे लगभग derive proc_macro में कर सकते हैं, सिवाय इसके कि हमें "इस प्रकार का Drop या Unpin " लागू न हो, इसके लिए एक तरीके की आवश्यकता होगी।

मुझे लगता है कि यह पता लगाने के प्रयास के लायक होगा कि पिन अनुमानों के लिए इस तरह के सुरक्षित एपीआई कैसे प्राप्त करें। हालाँकि, इसके लिए स्थिरीकरण को रोकना नहीं है: जिस एपीआई को हम यहाँ स्थिर करते हैं, वह सुरक्षित पिन अनुमानों के साथ संगत होना चाहिए। ( Unpin उपरोक्त जोर को लागू करने के लिए एक लंग आइटम बनना पड़ सकता है, लेकिन यह बहुत बुरा नहीं लगता है।)

पिनिंग नहीं है ! हटो

मैंने अक्सर C ++ के बारे में सोचा, जहां इन मुद्दों से बचा जाता है: प्रकारों को चल निर्माणकर्ता और असाइनमेंट ऑपरेटर को हटाने के द्वारा अस्वीकार्य घोषित किया जा सकता है। जब कोई प्रकार जंगम नहीं होता है, तो उस प्रकार के प्रकार भी शामिल नहीं होते हैं।

रस्ट के लिए अचूक प्रकारों को परिभाषित करने के लिए कई प्रयास किए गए थे। यह बहुत जल्दी जटिल हो जाता है।

समझने के लिए एक महत्वपूर्ण बात यह है कि पिनिंग अचूक प्रकार प्रदान नहीं करता है! सभी प्रकार जंग में जंगम रहते हैं। यदि आपके पास T , तो आप इसे अपनी इच्छानुसार कहीं भी स्थानांतरित कर सकते हैं। अचूक प्रकारों के बजाय, हम नए एन्कैप्सुलेटेड API को परिभाषित करने के लिए Rust की क्षमता का उपयोग करते हैं, क्योंकि हम एक पॉइंटर प्रकार को परिभाषित करते हैं Pin<&mut T> ) में हैं, न कि पॉइन्टी में ( T )। "मुझे कभी भी स्थानांतरित नहीं किया जा सकता" कहने के लिए एक प्रकार का कोई रास्ता नहीं है। हालांकि, एक प्रकार के लिए कहने का एक तरीका है " अगर मुझे पिन किया गया है , तो मुझे फिर से स्थानांतरित न करें"। एक तो MyFuture है कि मैं खुद को हमेशा चल होगा, लेकिन Pin<&mut MyFuture> का एक उदाहरण के लिए सूचक है MyFuture कि किसी भी अधिक ले जाया नहीं मिल सकता है।

यह एक सूक्ष्म बिंदु है, और हमें संभवतः इस सामान्य गलतफहमी से बचने में मदद करने के लिए डॉक्स को कुछ समय देना चाहिए।

लेकिन हम सभी में स्व-रेफरेंशियल पुनरावृत्तियों को व्यक्त किए बिना बहुत दूर हो गए हैं, यह सिर्फ एक उपयोग के मामले के लिए महत्वपूर्ण नहीं है।

ऐसा इसलिए है क्योंकि, अब तक, सभी पुनरावृत्तियों को एक प्रकार और impl Iterator for … ब्लॉक का उपयोग करके परिभाषित किया गया है। जब राज्य को दो पुनरावृत्तियों के बीच रखने की आवश्यकता होती है, तो इट्रेटर प्रकार के क्षेत्रों में इसे स्टैच करने और &mut self साथ काम करने के अलावा कोई विकल्प नहीं होता है।

हालांकि, भले ही यह भाषा में जनरेटर को शामिल करने के लिए प्राथमिक प्रेरणा नहीं है, यह अंततः बहुत अच्छा होगा जनरेटर yield वाक्यविन्यास का उपयोग करने के लिए कुछ ऐसा परिभाषित करने के लिए जो for साथ उपयोग किया जा सके yield उधार लेना क्योंकि जनरेटर-फ्यूचर्स के लिए बस उतना ही महत्वपूर्ण है जितना कि जनरेटर-फ्यूचर्स के लिए।

( Unpin उपरोक्त जोर को लागू करने के लिए एक लंग आइटम बनना पड़ सकता है, लेकिन यह बहुत बुरा नहीं लगता है।)

Unpin और Pin पहले से ही सुरक्षित अचल जनरेटर का समर्थन करने के लिए लैंग आइटम होने चाहिए।

सभी स्पष्टीकरण के लिए ठीक है धन्यवाद! मैं @Gankro से सहमत Pin बारे में नाममात्र की शैली वाला अध्याय और यहाँ बड़े पैमाने पर उपयोगी होगा। मुझे संदेह है कि विभिन्न सुरक्षित तरीके मौजूद हैं और क्यों असुरक्षित तरीके असुरक्षित हैं और ऐसा क्यों है, इसके लिए बहुत सारे विकास इतिहास हैं।

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

• fn new(P) -> Pin<P> where P: Deref, P::Target: Unpin

  • यह Pin<P> का निर्माण करने के लिए एक सुरक्षित तरीका है, और अस्तित्व में रहते हुए
    Pin<P> सामान्य रूप से मतलब है कि P::Target को फिर से कभी भी स्थानांतरित नहीं किया जाएगा
    कार्यक्रम, P::Target Unpin जो पढ़ा जाता है "की गारंटी"
    Pin अब धारण नहीं करते हैं। परिणामस्वरूप, यहां सुरक्षा इसलिए है क्योंकि वहाँ कोई नहीं है
    बनाए रखने की गारंटी देता है, इसलिए सब कुछ हमेशा की तरह आगे बढ़ सकता है।

• unsafe fn new_unchecked(P) -> Pin<P> where P: Deref

  • पिछले के विपरीत, यह फ़ंक्शन unsafe क्योंकि P नहीं है
    आवश्यक रूप से Unpin , इसलिए Pin<P> की गारंटी को बनाए रखना चाहिए
    P::Target Pin<P> बनने के बाद कभी भी फिर से नहीं चलेगा।

  इस गारंटी का उल्लंघन करने का एक तुच्छ तरीका, यदि यह फ़ंक्शन सुरक्षित है, दिखता है
  पसंद:

  fn foo<T>(mut a: T, b: T) {
      Pin::new_unchecked(&mut a); // should mean `a` can never move again
      let a2 = mem::replace(&mut a, b);
      // the address of `a` changed to `a2`'s stack slot
  }
  

  नतीजतन यह उपयोगकर्ता पर निर्भर है कि Pin<P> वास्तव में इसका मतलब है
  P::Target निर्माण के बाद फिर से कभी नहीं ले जाया जाता है, इसलिए यह unsafe !

• fn as_ref(&Pin<P>) -> Pin<&P::Target> where P: Deref

  • Pin<P> को देखते हुए हमारी गारंटी है कि P::Target कभी नहीं हिलेंगे। यही कारण है कि के
    Pin के अनुबंध का हिस्सा। परिणामस्वरूप इसका तुच्छ अर्थ है
    &P::Target , P::Target लिए एक और "स्मार्ट पॉइंटर" समान प्रदान करेगा
    गारंटी है, इसलिए &Pin<P> का सुरक्षित रूप से Pin<&P::Target> अनुवाद किया जा सकता है।

  यह Pin<SmartPointer<T>> से Pin<&T> जाने की एक सामान्य विधि है

• fn as_mut(&mut Pin<P>) -> Pin<&mut P::Target> where P: DerefMut

  • मेरा मानना ​​है कि यहां की सुरक्षा as_ref लगभग समान है।
    हम केवल एक Pin परस्पर उपयोग नहीं कर रहे हैं, इसलिए कुछ भी आसानी से नहीं किया जा सकता है
    अभी तक उल्लंघन किया है।

  प्रश्न : क्या "दुर्भावनापूर्ण" DerefMut निहित है? यह एक सुरक्षित तरीका है
  कॉल करने के लिए उपयोगकर्ता-प्रदान DerefMut जो &mut P::Target मूल रूप से,
  संभवतः इसे इसे संशोधित करने की भी अनुमति दे। यह कैसे सुरक्षित है?

• fn set(&mut Pin<P>, P::Target); where P: DerefMut

  • प्रश्न : Pin<P> (और इस तथ्य को देखते हुए कि हमें कुछ भी पता नहीं है
    Unpin ), क्या यह गारंटी नहीं होनी चाहिए कि P::Target कभी नहीं चलते हैं? अगर हम यह कर सकते हैं
    एक और P::Target साथ इसे फिर से संगठित करना, हालांकि, यह असुरक्षित नहीं होना चाहिए?
    या यह किसी भी तरह विध्वंसक और वह सब से संबंधित है?

• unsafe fn map_unchecked<U, FnOnce(&T) -> &U>(Pin<&'a T>, f: F) -> Pin<&'a U>

  • यह एक unsafe कार्य है इसलिए यहाँ मुख्य प्रश्न यह है कि "ऐसा क्यों नहीं है।"
    सुरक्षित "यदि यह सुरक्षित लगता है तो उल्लंघन की गारंटी का एक उदाहरण है:

  ...

  प्रश्न :: यहाँ प्रति-उदाहरण क्या है? यदि यह सुरक्षित थे, तो क्या है
  उदाहरण जो Pin की गारंटी का उल्लंघन करता हुआ दिखाता है?

• fn get_ref(Pin<&'a T>) -> &'a T

  • Pin<&T> की गारंटी का मतलब है कि T कभी नहीं चलेगा। &T लौट रहा है
    T उत्परिवर्तन की अनुमति नहीं देता है, इसलिए इसे बनाए रखने के दौरान सुरक्षित होना चाहिए
    यह गारंटी।

  एक "हो सकता है कि गोचा" यहाँ आंतरिक उत्परिवर्तन है, क्या होगा अगर T थे
  RefCell<MyType> ? यह, हालांकि, की गारंटी का उल्लंघन नहीं करता है
  Pin<&T> क्योंकि गारंटी केवल T के लिए पूरी तरह से लागू होती है, नहीं
  आंतरिक क्षेत्र MyType । जबकि आंतरिक परिवर्तनशीलता चारों ओर घूम सकती है
  आंतरिक, यह अभी भी मौलिक रूप से एक के पीछे पूरे ढांचे को स्थानांतरित नहीं कर सकता है
  & संदर्भ।

• fn into_ref(Pin<&'a mut T>) -> Pin<&'a T>

  • Pin<&mut T> मतलब है कि T कभी नहीं बढ़ेंगे। परिणामस्वरूप इसका अर्थ Pin<&T>
    एक ही गारंटी प्रदान करता है। इस रूपांतरण के साथ अधिक समस्या नहीं होनी चाहिए,
    यह ज्यादातर स्विचिंग प्रकार है।

• unsafe fn get_unchecked_mut(Pin<&'a mut T>) -> &'a mut T

  • Pin<&mut T> अर्थ है कि T कभी नहीं बढ़ना चाहिए, इसलिए यह तुच्छ unsafe
    क्योंकि आप T (सुरक्षित रूप से) ले जाने के परिणाम पर mem::replace उपयोग कर सकते हैं।
    unsafe यहाँ "हालांकि मैं आपको &mut T दे रहा हूँ, आपको कभी भी अनुमति नहीं है
    T "ले जाएँ।

• unsafe fn map_unchecked_mut<U, F: FnOnce(&mut T) -> &mut U>(Pin<&'a mut T>, f: F) -> Pin<&'a mut U>

  • मुझे लगता है कि unsafe यहां मूल रूप से कम से कम ऊपर के समान हैं, हम
    &mut T सुरक्षित रूप से सौंपना (एक असुरक्षित बंद करने की आवश्यकता नहीं हो सकती है)
    आसानी से mem::replace साथ उपयोग किया जा सकता है। यहाँ शायद अन्य बेवफ़ा भी हैं
    प्रक्षेपण के साथ, लेकिन यह उचित है कि यह कम से कम असुरक्षित है
    उसके कारण।

• fn get_mut(Pin<&'a mut T>) -> &'a mut T where T: Unpin

  • Unpin लागू करके एक प्रकार कहता है " Pin<&mut T> की कोई गारंटी नहीं है, यह है
    &mut T का एक नया आवरण। नतीजतन, कोई गारंटी नहीं है
    ऊपर, हम &mut T सुरक्षित रूप से वापस कर सकते हैं

• impl<P: Deref> Deref for Pin<P> { type Target = P::Target }

  • यह as_ref साथ सुरक्षित रूप से लागू किया जा सकता है, इसके बाद get_ref , इसलिए
    इस प्रत्यारोपण की सुरक्षा ऊपर से इस प्रकार है।

• impl<P: DerefMut> DerefMut for Pin<P> where T::Target: Unpin { }

  • यह as_mut साथ सुरक्षित रूप से लागू किया जा सकता है, इसके बाद get_mut , इसलिए
    इस प्रत्यारोपण की सुरक्षा ऊपर से इस प्रकार है।

• impl<T: ?Sized> Unpin for Box<T> (और अन्य सूचक-संबंधित कार्यान्वयन)

  • यदि कोई अन्य कार्रवाई नहीं की गई, तो Box<T> Unpin विशेषता लागू होगी
    केवल T लागू होने पर Unpin । यह कार्यान्वयन यहाँ पर भी संहिताबद्ध है
    यदि T स्पष्ट रूप से लागू नहीं करता है Unpin , Box<T> औजार Unpin ।

  प्रश्न : यह मौलिक रूप से सशक्त करने के लिए एक उदाहरण है?
  
  उदाहरण के लिए, अगर यह सुरक्षित है तो unsafe आवश्यकता होगी
  
  मौजूद नहीं था।

@ Matthias247 आप सुरक्षित रूप से पिन से म्यूट टी प्राप्त नहीं कर सकते हैं

> यदि T अनपिन नहीं है क्योंकि तब आप मेम को पिन से बाहर करने के लिए :: स्वैप कर सकते हैं, जो चीजों को पिन करने के उद्देश्य को हरा देगा।

धन्यवाद! हां, चूंकि swap कोई असुरक्षित विधि नहीं है, Unpin swap() जोड़कर तय किया जा सकता है? चूंकि अब तक के सभी कोड Unpin होने चाहिए या वैसे भी असुरक्षित हैं, इससे कुछ भी टूटना नहीं चाहिए।

मैं उन चीजों में से एक का अनुमान लगाता हूं जो अभी भी मुझे सबसे ज्यादा भ्रमित करती हैं, वह यह है कि Pin<T> कई गारंटियों को संहिताबद्ध करती है: टी का पता स्थिर है, साथ ही कुछ गारंटी यह आंतरिक स्थिति के बारे में है (यह कुछ में स्थिर / अपरिवर्तनीय है। स्थितियों, लेकिन यह भी वास्तव में नहीं)।

यह मुझे असुरक्षित कोड / अनुमानों को केवल उन जगहों पर ले जाने जैसा लगता था, जहां Pin आधारित कॉल की आवश्यकता होती है (जैसे कि poll s खेतों पर) उन असुरक्षित अनुमानों से निपटने के लिए बेहतर हो सकता है सभी मामले। हालाँकि मुझे अब यह भी पता चला कि इसके साथ एक और मुद्दा है: परस्पर संदर्भ के लिए उपयोग किया गया कोड फ़ील्ड को स्वतंत्र रूप से चारों ओर ले जा सकता है, और जब drop() को सुरक्षित रूप से इस फ़ील्ड पर कॉल किया जाता है, तो इसके कारण टूट सकता है पता कहीं और संग्रहीत किया जा रहा है। उसके लिए drop(Pin<T>) अधिभार के बारे में बात की गई थी, जिसकी आवश्यकता होगी।

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

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

T: Unpin mem::swap जोड़ने का मतलब है कि इसका उपयोग कुछ प्रकारों पर भी नहीं किया जा सकता है, जब वे पिन के अंदर न हों।

लेकिन क्या स्वैप () में बंधे अनपिन को जोड़कर इसे ठीक किया जा सकता है? चूंकि अब तक का सभी कोड अनपिन होना चाहिए या वैसे भी असुरक्षित है, इसलिए इसे कुछ भी नहीं तोड़ना चाहिए।

यह सभी सामान्य कोड को तोड़ देगा: यदि आप आज के स्थिर जंग में कुछ T कमी के बिना एक फ़ंक्शन लिखते हैं, तो आप उस पर swap कॉल कर सकते हैं। इसके लिए काम करते रहना होगा।

गैर-जंगम प्रकार बहुत अधिक जटिलता को पेश किए बिना बहुत अच्छी तरह से काम करते हैं।

किसी ने गैर-जंगम प्रकारों को जंग में जोड़ने के लिए काफी हद तक यहां स्थिरीकरण के लिए प्रस्तावित किया जा रहा है। आपको RFC रेपो में इन पुराने प्रस्तावों और चर्चाओं में से कुछ का पता लगाना चाहिए। एक उदाहरण के लिए https://github.com/rust-lang/rfcs/pull/1858 देखें।

Https://github.com/rust-lang/rfcs/pull/2349 के साथ-साथ यहां शुरू होने वाली नाव की ब्लॉग श्रृंखला आपको कुछ पृष्ठभूमि और कुछ अन्य डिजाइनों की छाप देने में मदद करनी चाहिए, जिन पर विचार किया गया था। (तिथियों पर भी ध्यान दें, यह डिज़ाइन लगभग 10 महीनों के लिए काम में है!)

यह भी मेम :: स्वैप एक लाल हेरिंग है, क्योंकि यह एक दिलचस्प कार्य नहीं है। यह सचमुच है

let temp = *a; 
*a = *b; 
*b = temp;

@Gankro क्या यह असुरक्षित कोड का उपयोग नहीं करता है? Afaik यह सचमुच लिखना संभव नहीं है।

संपादित करें: मुझे लगता है कि इस बारे में सोचने का एक और तरीका यह है कि T: Unpin mem::swap जोड़ना वास्तव में भाषा स्तर पर सुरक्षा की परिभाषा बदल रहा है। यह जंगली में सभी mycrate::swap fns को तोड़ देगा।

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

यदि अनपिन स्वचालित रूप से प्राप्त होता है (उसी तरह से Sync / Send हैं) तो मुझे लगा कि यह कोई मुद्दा नहीं होना चाहिए।

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

लेकिन यह स्पष्ट रूप से एक है इस तथ्य के बारे में नहीं सोचा था कि विशेषता सीमा को स्पष्ट रूप से जंग में प्रचारित करने की आवश्यकता है।

किसी ने गैर-जंगम प्रकारों को जंग में जोड़ने के लिए एक पिछड़े-संगत तरीके से जोड़ने का तरीका नहीं दिखाया है, बिना जटिलता के काफी हद तक यहाँ स्थिरीकरण के लिए प्रस्तावित किया जा रहा है। आपको RFC रेपो में इन पुराने प्रस्तावों और चर्चाओं में से कुछ का पता लगाना चाहिए। एक उदाहरण के लिए जंग-लंग / rfcs # 1858 देखें।

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

@ Matthias247

यदि अनपिन स्वचालित रूप से व्युत्पन्न है (उसी फैशन में सिंक / सेंड हैं) तो मुझे लगा कि यह कोई मुद्दा नहीं होना चाहिए।

मुझे यकीन नहीं है कि मैं स्पष्ट था। स्पष्ट करने के लिए, एक !Unpin प्रकार के चारों ओर घूमना पूरी तरह से सुरक्षित है और इस प्रकार mem::swap लगभग सुरक्षित है। पिन किए जाने के बाद T: !Unpin टाइप करना केवल असुरक्षित है, अर्थात Pin<P<T>> ।

उदाहरण के लिए, async / प्रतीक्षारत कोड में, आप async फ़ंक्शन से दिए गए वायदा को जितना चाहें उतना स्थानांतरित कर सकते हैं। जब आप pin_mut! एक बार उन्हें स्थानांतरित करने में सक्षम होते हैं या उन्हें Pin<Box<..>>> या whatnot में डाल देते हैं, तो आप उन्हें रोक सकते हैं।

मेरे पास इसके बारे में कुछ मिश्रित प्रश्न हैं:

1. Pin<T> async और जनरेटर के लिए और जब जंग के अन्य भागों (जैसे swap replace ) के साथ बातचीत करने के लिए संभावित के महत्व को देखते हुए, कोई भी है औपचारिक सत्यापन (जैसे @jhjourdan या @RalfJung द्वारा) यहां प्रस्तावित पिनिंग संस्करण के प्रकार से किया गया है?

2. क्या यह एपीआई Rust की अमूर्त मशीन / परिचालन शब्दार्थ के बारे में कोई नई गारंटी देता है? Ie, अगर हम async & await / जनरेटर के लिए एक बैकिंग तंत्र के रूप में उपयोग के मामले के बारे में भूल जाते हैं, तो क्या हम इसे पारिस्थितिकी तंत्र में एक टोकरा के अंदर रख सकते हैं और यह सिर्फ वर्तमान में दिए गए काम को पूरा करेगा। दे सकता है?

3. पिनिंग एपीआई को स्थिर करने के परिणामस्वरूप किस प्रकार के एपीआई या प्रकार के सिस्टम जोड़ असंभव हो जाते हैं? (यह सवाल 2 का विस्तार है)

4. टू-बी-स्टेब्लाइज्ड एपीआई क्या रास्ते प्रदान करता है यह क्षेत्र के प्रक्षेपण पर सुधार करने के लिए &pin T प्रदान की गई भाषा के रूप में प्रदान करता है और (जो प्रस्तावित एपीआई के साथ बहुत अच्छा नहीं लगता है)।

मेरे पास कुछ मिश्रित नोट हैं:

1. मानक पुस्तकालय में प्रलेखन काफी विरल लगता है। :(

2. मैं दूसरों से सहमत हूं कि पिनिंग निर्माण काफी मानसिक रूप से कर / जटिल है।

3. प्रलेखन में Unmovable उदाहरण अत्यधिक जटिल लगता है और इसमें unsafe ; यह उप-इष्टतम लगता है। क्रमिक आरंभीकरण के साथ एक ड्राफ्ट में आरएफसी को भाषा

struct Unmovable<'a> {
    data: String,
    slice: &'a str,
}

let um: Unmovable<'_>;
um.data = "hello".to_string();
um.slice = &um.data; // OK! we borrow self-referentially.

drop(um); // ERROR! `um.slice` is borrowing `um.data` so you cannot move `um`.

// You won't be able to take a &mut reference to `um` so no `swap` problems.

इसमें शून्य असुरक्षित शामिल है और उपयोगकर्ता के लिए इससे निपटना काफी आसान है।

इसके अतिरिक्त, std API स्टैक में ऑब्जेक्ट्स को पिन करने का कोई सुरक्षित तरीका प्रदान नहीं करता है।
ऐसा इसलिए है क्योंकि फ़ंक्शन एपीआई का उपयोग करके सुरक्षित रूप से लागू करने का कोई तरीका नहीं है।

इस तरह से एपीआई के बारे में क्या?

pub fn using_pin<T, R, F>(value: T, f: F) -> R
where F: for<'a> FnOnce(Pin<&'a mut T>) -> R {
    pin_mut!(value);    // Actual implementation inlines this but the point is this API is safe as long as pin_mut! is safe.
    f(value)
}

मैं पिनिंग एपीआई के विकास के साथ-साथ बहुत निकटता से पालन नहीं कर रहा हूं, इसलिए इसका उल्लेख कहीं और किया जा सकता है या मैं इसे खोजने में असमर्थ हूं, अगर ऐसा है तो माफी माँगता हूँ:

Pinned प्रकार एक ZST है जो Unpin लागू नहीं करता है; यह आपको अनुमति देता है
Unpin के ऑटो-कार्यान्वयन को स्थिर पर दबाएं, जहां !Unpin निहित है
अभी तक स्थिर नहीं होगा।

क्या !Unpin निहितार्थ को स्थिर नहीं बनाया जा सकता है, इस बारे में कहीं भी स्पष्टीकरण है?

यह केवल तभी सुरक्षित है जब फू (युक्त प्रकार) repr (पैक) नहीं है,
क्योंकि इससे खेतों को स्थानांतरित करने के लिए उन्हें स्थानांतरित करने का कारण बनता है।

क्या पैक्ड का मतलब है कि खेतों को गतिशील रूप से स्थानांतरित किया जा सकता है? यह थोड़ा डरावना है। क्या हमें यकीन है कि अन्य परिस्थितियों में फ़ील्ड को स्थानांतरित करने के लिए llvm कभी भी कोड उत्पन्न नहीं करेगा? इसी तरह यह संभव है कि स्टैक पर मौजूद मान को llvm द्वारा स्थानांतरित किया जाए?

सूक्ष्मता के बावजूद, यह वास्तव में एक अच्छा एपीआई जैसा लगता है। अच्छा कार्य!

@Centril Ralf ने अपने ब्लॉग पर पिन

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

Pin वास्तव में रस्ट की सबसे मूल्यवान और क्लासिक विशेषताओं में से एक का सिर्फ एक चतुर कार्यान्वयन है: एपीआई unsafe भाग को चिह्नित करके एक एपीआई के लिए हमलावरों को पेश करने की क्षमता। Pin एक ऑपरेशन करने के लिए एक पॉइंटर को लपेटता है ( DerefMut ) असुरक्षित, इसके लिए आवश्यक है कि जो लोग ऐसा करते हैं वे कुछ आक्रमणकारियों (जो वे संदर्भ से बाहर नहीं निकलते हैं) और अन्य कोड को अनुमति देते हैं यह मान लें कि यह कभी नहीं होगा। इसी ट्रिक का एक समान, अधिक पुराना उदाहरण String , जो गैर-UTF8 बाइट्स को एक स्ट्रिंग में डालने के लिए असुरक्षित बनाता है, जिससे अन्य कोड यह मान सकता है कि String में सभी डेटा है। UTF8।

वहाँ के बारे में कहीं भी स्पष्टीकरण क्यों है? Unpin प्रत्यारोपण स्थिर नहीं बनाया जा सकता है?

वर्तमान में नकारात्मक प्रभाव अस्थिर हैं, पूरी तरह से इन एपीआई से असंबंधित हैं।

वर्तमान में नकारात्मक प्रभाव अस्थिर हैं।

,🤦 that जो समझ में आता है, उसके बारे में थोड़ा अधिक समय तक सोचना चाहिए। धन्यवाद।

@alexcrichton इस एपीआई का कुछ महान विश्लेषण है, हमें इसे कुछ टिप्पणी से बेहतर कुछ जगह को संरक्षित करने की कोशिश करनी चाहिए जो खो जाएगी!

कुछ टिप्पणियां:

as_mut : प्रश्न: एक "दुर्भावनापूर्ण" DerefMut निहित के बारे में क्या? यह एक सुरक्षित तरीका है
कॉल करने के लिए एक उपयोगकर्ता-प्रदान DerefMut जो टोकरा और म्यूट P :: लक्ष्य मूल रूप से,
संभवतः इसे इसे संशोधित करने की भी अनुमति दे। यह कैसे सुरक्षित है?

असल में, जब आप new_unchecked कॉल करते हैं, तो आप इस प्रकार के लिए Deref और DerefMut बारे में एक वादा करते हैं।

set : दिया पिन

(और यह तथ्य कि हम कुछ भी नहीं जानते हैं
अनपिन), क्या यह गारंटी नहीं होनी चाहिए कि P :: लक्ष्य कभी भी नहीं चलता है? अगर हम यह कर सकते हैं
किसी अन्य P :: लक्ष्य के साथ इसे पुन: व्यवस्थित करें, हालांकि, यह असुरक्षित नहीं होना चाहिए?
या यह किसी भी तरह विध्वंसक और वह सब से संबंधित है?

यह पॉइंटर के पुराने कंटेंट को ड्राप करता है, और वहां नया कंटेंट डालता है। "पिन किया हुआ" का मतलब "कभी नहीं गिराया गया" है, इसका मतलब है कि "कभी भी गिराया नहीं गया"। इसलिए drop कॉल करते समय इसे ड्रोप करना या इसे ओवरराइट करना ठीक है। drop कॉल करना महत्वपूर्ण है, यही ड्रॉप गारंटी है जिसका मैंने ऊपर उल्लेख किया है।

आपको यहां कुछ चलता दिखाई देता है?

map_unchecked : प्रश्न :: यहाँ प्रति-उदाहरण क्या है? यदि यह सुरक्षित थे, तो क्या उदाहरण है जो पिन की गारंटी का उल्लंघन करता है?

एक उदाहरण Pin<&&T> साथ शुरू होगा और Pin<&T> प्राप्त करने के लिए इस पद्धति का उपयोग करेगा। पिनिंग "संदर्भों के माध्यम से" प्रचार नहीं करता है।

get_ref : एक "शायद gotcha" यहाँ आंतरिक उत्परिवर्तन है, अगर टी थे तो क्या होगा
RefCell?

वास्तव में, यह एक गोच है, लेकिन जैसा कि आपने देखा कि एक ध्वनि समस्या नहीं है। क्या होगा , यह एक तरीका है जो Pin<RefCell<T>> से Pin<&[mut] T> । असल में, क्या होता है कि RefCell पिनिंग का प्रचार नहीं करता है, हम impl<T> Unpin for RefCell<T> ।

क्या कोई औपचारिक सत्यापन (जैसे @jhjourdan या @RalfJung द्वारा) किया गया है जो यहाँ प्रस्तावित एपीआई के वैरिएंट से किया गया है?

नहीं, हमारी तरफ से नहीं। जिन ब्लॉग पोस्टों का मैंने ऊपर उल्लेख किया है उनमें कुछ विचार हैं कि मैं इसे कैसे औपचारिक रूप देना शुरू करूँगा, लेकिन हमने वास्तव में इसे पूरा नहीं किया है। यदि आप मुझे एक टाइम मशीन या इच्छुक पीएचडी छात्र देते हैं तो हम इसे करेंगे। ;)

यदि हम async और इंतजार / जनरेटर के लिए एक समर्थन तंत्र के रूप में उपयोग के मामले के बारे में भूल जाते हैं, तो क्या हम इसे पारिस्थितिक तंत्र में एक टोकरा के अंदर रख सकते हैं और यह सिर्फ वर्तमान गारंटी हम दिया काम करेंगे?

यही इरादा है।

पिनिंग एपीआई को स्थिर करने के परिणामस्वरूप किस प्रकार के एपीआई या प्रकार के सिस्टम जोड़ असंभव हो जाते हैं? (यह सवाल 2 का विस्तार है)

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

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

मुझे यकीन नहीं है कि &pin T , यह बहुत अच्छी तरह से नए सामान्य Pin<T> मेल नहीं खाता। अनुमानों को संभालने के संदर्भ में, हमें " Unpin और Drop इस प्रकार के लिए लागू नहीं किया गया" कहने के लिए कुछ हैक की आवश्यकता होगी, फिर हम इसे मैक्रो के साथ सुरक्षित रूप से कर सकते हैं। अतिरिक्त एर्गोनॉमिक्स के लिए, हम संभवतः भाषा में एक सामान्य "फ़ील्ड प्रोजेक्शन" क्षमता चाहते हैं, एक वह जो &Cell<(A, B)> से &Cell<A> ।

वहाँ के बारे में कहीं भी स्पष्टीकरण क्यों है? Unpin प्रत्यारोपण स्थिर नहीं बनाया जा सकता है?

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

हो सकता है कि चाक यह सब ठीक कर दे, हो सकता है कि इसमें से कुछ हो, लेकिन किसी भी तरह हम शायद चाक पर इसे रोकना नहीं चाहेंगे।

क्या पैक्ड का मतलब है कि खेतों को गतिशील रूप से स्थानांतरित किया जा सकता है? यह थोड़ा डरावना है।

यह एक पैक क्षेत्र पर drop कॉल करने का एकमात्र ध्वनि तरीका है, जिसे देखते हुए drop एक संयुक् त संदर्भ की अपेक्षा करता है।

क्या हमें यकीन है कि अन्य परिस्थितियों में फ़ील्ड को स्थानांतरित करने के लिए llvm कभी भी कोड उत्पन्न नहीं करेगा? इसी तरह यह संभव है कि स्टैक पर मौजूद मान को llvm द्वारा स्थानांतरित किया जाए?

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

ठीक है धन्यवाद @RalfJung , समझ में आता है! कुछ अनुवर्ती प्रश्न ...

जब आप कहते हैं कि "कभी नहीं गिराया जब तक", इसका मतलब है कि Drop कहा जा सकता है जहाँ &mut self Pin<&mut Self> के पते से स्थानांतरित हो गया है? विध्वंसक सही, सही होने के आंतरिक बिंदुओं पर भरोसा नहीं कर सकते हैं?

set को देखते समय मेरी चिंता यह थी कि पैनिक को कैसे संभाला जाएगा, लेकिन मुझे लगता है कि कोडगैन में थोड़ा और खुदाई करने के बाद यह एक गैर-मुद्दा है।

जब आप कहते हैं कि "कभी नहीं गिराया जब तक", इसका मतलब है कि Drop कहा जा सकता है जहाँ &mut self Pin<&mut Self> के पते से स्थानांतरित हो गया है? विध्वंसक सही, सही होने के आंतरिक बिंदुओं पर भरोसा नहीं कर सकते हैं?

@alexcrichton मेरी समझ यह थी कि Drop::drop रिटर्न के बाद कभी भी स्थानांतरित नहीं हुआ। अन्यथा कुछ usecases (घुसपैठ संग्रह और स्टैक आवंटित DMA बफ़र्स कम से कम) असंभव हो जाते हैं।

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

कोड यह नहीं मान सकता है कि गैर- विध्वंसक विनाशकर्ता सदस्यों को स्थानांतरित नहीं करते हैं, लेकिन जाहिर है आप यह मान सकते हैं कि आपके स्वयं के विध्वंसक चीजों को इधर-उधर नहीं करते क्योंकि आप उन्हें लिख रहे हैं।

जब आप कहते हैं कि "जब तक नहीं गिराया जाता है, तब तक", इसका मतलब है कि ड्रॉप को कहा जा सकता है जहां और पिन के पते से <और स्वयं को स्थानांतरित किया गया है? विध्वंसक सही, सही होने के आंतरिक बिंदुओं पर भरोसा नहीं कर सकते हैं?

मेरा मतलब है कि जब तक drop कॉल नहीं किया जाता, तब तक डेटा कभी नहीं जाएगा (कहीं और नहीं जाने की, जिसमें शामिल नहीं है)। और हां, drop पिन किए गए स्थान पर चलने पर भरोसा कर सकते हैं, भले ही इसका प्रकार यह व्यक्त नहीं कर सकता है। drop को Pin<&mut self> (सभी प्रकार के लिए) चाहिए, लेकिन अफसोस, इसके लिए बहुत देर हो चुकी है।

drop कहे जाने के बाद, डेटा सिर्फ अर्थहीन बाइट्स है, आप उनके साथ कुछ भी कर सकते हैं: नया सामान वहां रखें, डीललेट करें, जो भी हो।

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

मैं सभी के माध्यम से पढ़ रहा हूं, मैं Pin , Unpin , और इस पर चर्चा कर रहा हूं, और जब मैंने _think_ को समझा, तो अब बहुत हो रहा है विभिन्न प्रकार के अर्थों के साथ-साथ कार्यान्वयनकर्ताओं और उपयोगकर्ताओं को अनुबंध का पालन करना होगा। अफसोस की बात है, मैं डॉक्स में std::pin या Pin और Unpin विशेष रूप से बहुत कम चर्चा देखता हूं। विशेष रूप से, मैं इन टिप्पणियों में से कुछ सामग्री देखना पसंद करूंगा:

• https://github.com/rust-lang/rust/issues/55766#issuecomment -436782229
• https://github.com/rust-lang/rust/issues/55766#issuecomment -437428085
• https://github.com/rust-lang/rust/issues/55766#issuecomment -437846602
• https://github.com/rust-lang/rust/issues/55766#issuecomment -437987966

डॉक्स में शामिल। विशेष रूप से:

• वह Pin केवल "एक स्तर गहरे" की रक्षा करता है।
• वह Pin::new_unchecked Deref DerefMut लिए निहितार्थ पर प्रतिबंध लगाती है।
• Pin और Drop के बीच की सहभागिता।
• कैसे !Unpin को केवल Pin में रखने की अनुमति नहीं है।
• Pin<Box<T>>: Unpin where T: !Unpin लिए तर्क। यह ऊपर दिए गए "वन लेवल डीप" प्रतिबंध से जुड़ा है, लेकिन मुझे लगता है कि एक उचित स्पष्टीकरण के साथ यह ठोस उदाहरण पाठकों के लिए उपयोगी होगा।

मुझे @alexcrichton का काउंटर-उदाहरण बहुत मददगार लगा। पाठक को इस बात का अंदाजा देना कि अलग-अलग unsafe तरीकों के लिए क्या गलत हो सकता है, बस मुझे लगता है कि बहुत मदद मिलेगी (कम से कम यह निश्चित रूप से मेरे लिए किया था)। सामान्य तौर पर, इस एपीआई की सूक्ष्मता के कारण, मैं विस्तारित किए गए विभिन्न असुरक्षित तरीकों के सुरक्षा वर्गों को देखना चाहूंगा, और संभवतः std::pin मॉड्यूल-स्तरीय डॉक्स से भी संदर्भित किया जा सकता है।

मैंने स्वयं अभी तक इस API का उपयोग नहीं किया है, इसलिए मैं तकनीकी निर्णय पर विश्वास करूँगा कि अब यह एक अच्छी स्थिति में है। हालाँकि, मुझे लगता है कि नाम Pin , Pinned और Unpin बहुत भिन्न प्रकार / लक्षण और एक अपेक्षाकृत जटिल API के लिए बहुत समान हैं, जो इसे समझने में कठिन बनाता है। (जैसा कि इस धागे पर कुछ टिप्पणियों से स्पष्ट है)।

वे मार्कर लक्षणों के लिए नामकरण सम्मेलनों का पालन करते हैं, इसलिए मैं वास्तव में शिकायत नहीं कर सकता, लेकिन मुझे आश्चर्य है कि क्या हम क्रियात्मकता और स्व-व्याख्या नामों के बीच एक व्यापार कर सकते हैं:

• Pinned - भ्रामक है क्योंकि इसका समान शब्द Pin । यह देखते हुए कि इसका उपयोग PhantomData जैसे मेटा सूचना के साथ एक संरचना को बढ़ाने के लिए किया गया है जो अन्यथा गायब हो जाएगा, कैसे PinnedData , PhantomPinned , PhantomSelfRef या DisableUnpin ? कुछ ऐसा है जो उपयोग पैटर्न और / या इसके होने वाले प्रभाव को इंगित करता है।
• Unpin - जैसे https://github.com/rust-lang/rust/issues/55766#issuecomment -437266922, मैं Unpin के नाम से भ्रमित हूं, क्योंकि "अन-पिन" "कई अस्पष्ट तरीकों से समझा जा सकता है। IgnorePin , PinNeutral शायद कुछ?

आम तौर पर मैं असफल रहा हूँ और अपने आप को अच्छे वैकल्पिक नाम ढूँढ रहा हूँ ...

PhantomPin और PinNeutral ने मुझे विशेष रूप से अच्छे नामों के रूप में हड़ताल किया।

बस एक काउंटरपॉइंट प्रदान करने के लिए, मैंने Unpin सहज (एक बार जब मैंने इसे समझ लिया है) पाया है। Pinned सीधे रखना कठिन है, बशर्ते मैंने अपने कोड में इसका उपयोग न किया हो। Pinned से NotUnpin बदलने के बारे में क्या?

मैं इस बात से सहमत हूं कि बेहतर नामों की खोज करना एक सार्थक व्यायाम हो सकता है, जिसके बारे में बात करना आसान हो। मैंने प्रस्ताव रखा है:

• Pin -> Pinned : जब आपको Pin , तो यह वास्तव में एक वादा है कि आपको क्या दिया गया है _ _ pinned_, और _remain_ हमेशा के लिए पिन किया जाएगा। मैं इस बारे में बहुत दृढ़ता से महसूस नहीं करता, क्योंकि आप _could_ के बारे में भी बात करते हैं, जिसे "एक मूल्य का पिन" दिया जाता है। Pinned<Box<T>> सिर्फ मेरे लिए अच्छे को पढ़ता है, विशेष रूप से इसमें केवल Box को पिन किया जाता है, न कि इसमें मौजूद सामान को।
• Unpin -> Repin : अन्य मार्कर लक्षणों के लिए, हम आम तौर पर इस बारे में बात करते हैं कि आप उस मार्कर विशेषता के साथ क्या कर सकते हैं। जो संभवतः Unpin पहले स्थान पर चुना गया था। हालाँकि, मुझे लगता है कि हम वास्तव में पाठक को यहाँ ले जाना चाहते हैं, ऐसा कुछ ऐसा है जो Unpin पिन किया जा सकता है, और फिर परिणाम या विचार के बिना कहीं और फिर से पिन किया जा सकता है। मुझे PinNeutral @ चिह्न-इम के सुझाव भी पसंद हैं, हालांकि यह कुछ हद तक अधिक क्रिया है।
• Pinned -> PermanentPin : मुझे नहीं लगता कि Pinned एक अच्छा नाम है, क्योंकि कुछ जिसमें Pinned , वास्तव में पिन नहीं किया गया है .. बस नहीं है Unpin । PhantomPin में एक समान मुद्दा है कि यह Pin को संदर्भित करता है, जब Pin वास्तव में वह चीज नहीं है जिसे आप प्राप्त करना चाहते हैं। NotUnpin पास एक डबल नकारात्मक है, जिसके बारे में तर्क करना मुश्किल है। @ किमुंडी का PhantomSelfRef बहुत पास हो जाता है, हालांकि मुझे अभी भी लगता है कि यह थोड़ा "जटिल" है, और यह संपत्ति को "एक बार पिन नहीं किया जा सकता" को एक उदाहरण के साथ रखता है जहां मामला है (जब आप एक आत्म संदर्भ है)। मेरे सुझाव को PermanentlyPinned रूप में भी अभिव्यक्त किया जा सकता है; मुझे नहीं पता कि कौन सा रूप कम बुरा है।

मुझे लगता है कि Pinned का अंत होना चाहिए NotX जहां X जो भी Unpin समाप्त होता है उसका नाम रखा जा रहा है। Pinned का एकमात्र काम इसे बनाना है, ताकि संलग्न प्रकार Unpin लागू न हो। (संपादित करें: और यदि हम Unpin को किसी और चीज़ में बदल रहे हैं, तो संभवतः दोहरा नकारात्मक कोई मुद्दा नहीं है)

Repin मेरे लिए कोई मतलब नहीं है, क्योंकि "इस प्रकार को कहीं और पिन किया जा सकता है" "यह प्रकार एक पिन से बाहर ले जाया जा सकता है" का सिर्फ एक साइड इफेक्ट है।

@tikue कुछ अर्थों में मैं ऐसा ही महसूस करता हूं, लेकिन रिवर्स में। मुझे लगता है कि Unpin नेगेटिव में "" यह _not_ Pin विवश है, जबकि Pinned को सकारात्मक "" ___ में Pin करके सकारात्मक होना चाहिए। s/Unpin/TemporaryPin , s/Pinned/PermanentPin ?

संपादित करें: हाँ, मैं Repin Unpin साइड-इफ़ेक्ट होने के बारे में आपकी बात देखता हूँ। मैं इस तथ्य को संप्रेषित करना चाहता था कि Pin " Unpin प्रकार के लिए" महत्वहीन "है, जो मुझे नहीं लगता कि Unpin सुपर अच्छी तरह से करता है। इसलिए TemporaryPin ऊपर का सुझाव।

@ जोंहू मुझे लगता है कि मुख्य कारण मुझे पसंद है क्योंकि विपरीत Pinned एक गुण को कार्यान्वित होने से रोकता है, इसलिए, मेरे लिए सबसे सरल अर्थ में, वास्तविक नकारात्मक है।

संपादित करें: किस बारे में:

Unpin -> Escape
Pinned -> NoEscape

दिलचस्प है .. मैं यह देखने की कोशिश कर रहा हूं कि यह कैसे प्रलेखन में फिट होगा। कुछ इस तरह:

सामान्य तौर पर, जब आपको Pin<P> , तो यह गारंटी के साथ आता है कि P का लक्ष्य तब तक नहीं हटेगा जब तक इसे गिरा नहीं दिया जाता। इसका अपवाद यदि P का लक्ष्य Escape । प्रकारों को Escape के रूप में चिह्नित किया गया है जो वे स्थानांतरित होने पर भी मान्य रहते हैं (उदाहरण के लिए, उनमें कोई आंतरिक आत्म-संदर्भ नहीं है), और इसलिए उन्हें Pin "बच" जाने दिया जाता है। Escape एक ऑटो-विशेषता है, इसलिए सभी प्रकार जो पूरी तरह से प्रकार के होते हैं, जो Escape होते हैं, वे भी Escape । कार्यान्वयन करने वालों रात के प्रयोग पर इस से बाहर निकल सकते impl !Escape for T {} , या शामिल करके NoEscape से मार्कर std::phantom ।

यह बहुत अच्छा लगता है, हालांकि शब्द "बच" का संबंध थोड़ा सा कठिन है। अलग-अलग, ऊपर लिखने से मुझे यह भी एहसास हुआ कि Pin<P> _really_ गारंटी नहीं देते कि P का लक्ष्य स्थानांतरित नहीं किया जाएगा ( Unpin ठीक होने के कारण)। इसके बजाय, यह गारंटी देता है कि _either_ इससे कोई फर्क नहीं पड़ता कि P का लक्ष्य चलता है _or_ P का लक्ष्य स्थानांतरित नहीं होगा। पता नहीं कैसे उपयोग करें कि नामों के बेहतर विकल्प को सूचित करने के लिए ... लेकिन यह शायद ऐसा कुछ है जो इसे डॉक्स में एक तरह से या किसी अन्य तरीके से बनाना चाहिए।

व्यक्तिगत रूप से, मेरे पास एक नाम के रूप में Unpin लिए एक बड़ी नापसंद है, हो सकता है क्योंकि यह सबसे अधिक बार impl !Unpin रूप में देखा जाता है जो "न-अन-पिन" पढ़ता है और कई मस्तिष्क-चक्रों की आवश्यकता होती है (I यह निष्कर्ष निकालने का मतलब है कि "पहली बार पिन किए जाने पर इसे हमेशा के लिए पिन कर दिया जाएगा", इसलिए मैं दोहरे नकारात्मक को दूर नहीं कर सकता।
सामान्य तौर पर, मनुष्यों को सकारात्मक (एक प्रत्यक्ष स्रोत के बिना, लेकिन संदेह में अगर रिचर्ड हडसन के काम की जाँच करें) के बजाय नकारात्मक परिस्थितियों में सोचने में कठिन समय लगता है।
Btw Repin मेरे लिए बहुत अच्छा लगता है।

Pin को समझाना कठिन है क्योंकि यह हमेशा पिन किए गए मूल्य को अचल नहीं बनाता है। Pinned भ्रमित है क्योंकि यह वास्तव में कुछ भी नहीं पिन करता है। यह सिर्फ Pin भागने से रोकता है।

Pin<P<T>> को पिन किए गए मूल्य के रूप में समझाया जा सकता है: पिन किए गए मान तब तक नहीं चल सकते जब तक कि मूल्य एक प्रकार नहीं है जो पिन से बच सकता है।

कुछ त्वरित गुगली से पता चलता है कि कुश्ती में, जब किसी को पिन किया जाता है, तो पिन से तोड़कर भागने को

मुझे Unpin बजाय टर्म एस्केप भी पसंद है लेकिन मैं EscapePin लिए जाऊंगा।

यहाँ बहुत अच्छे विचार हैं!

एक सामान्य बात: मेरे लिए एक गैर-देशी वक्ता के रूप में Pin और Unpin अधिकांशतः क्रिया या कार्य होते हैं। जबकि Pin अर्थ होता है, चूंकि ऑब्जेक्ट को एक बार में एक मेमोरी स्थान पर पिन किया जाता है, मैं Unpin लिए समान नहीं देख सकता। एक बार जब मुझे Pin<&mut T> का संदर्भ मिलता है, तो T को हमेशा इस अर्थ में पिन किया जाएगा कि यह मेमोरी स्थान स्थिर है, चाहे वह Unpin या न हो। यह वास्तव में एक कार्रवाई के रूप में एक वस्तु को खोलना संभव नहीं है। अंतर यह है कि Unpin प्रकारों को आगे के इंटरैक्शन में बनाए रखने के लिए पिनिंग की गारंटी की आवश्यकता नहीं होती है। वे स्व-संदर्भ नहीं हैं, और उनका मेमोरी एड्रेस उदाहरण के लिए किसी अन्य ऑब्जेक्ट पर नहीं भेजा जाता है और वहां संग्रहीत किया जाता है।

मैं @tikue से सहमत हूं कि Unpin वास्तव में मतलब क्या है, इसके लिए एक हड़ताली काम करना अच्छा होगा, लेकिन इसे निर्धारित करना कठिन है। यह विशुद्ध रूप से नहीं है कि वे प्रकार चल रहे हों, और यह विशुद्ध रूप से उनकी आत्म-संदर्भितता की कमी भी नहीं है? हो सकता है कि यह "पूरे मेमोरी स्पेस में कोई पॉइंटर्स नहीं है जब ऑब्जेक्ट को ले जाया गया हो तो अमान्य हो जाता है"। तब StableOnMoveAfterPin , या सिर्फ StableMove जैसा कुछ विकल्प हो सकता है, लेकिन वे भी वास्तव में महान नहीं लगते हैं।

Repin मेरे लिए Unpin रूप में एक ही जटिलताएं हैं, जो यह है कि इसका तात्पर्य यह है कि पहली चीज अनपिन हो जाती है - जो मेरी समझ में नहीं आता है।

चूंकि लक्षण ज्यादातर परिभाषित करता है कि एक के बाद क्या होता है Pin प्रकार का, मुझे PinNeutral या PinInvariant जैसी चीजें बहुत बुरी नहीं लगती हैं।

Pin Pinned , मुझे लगता है कि मैं Pinned पसंद करूंगा, क्योंकि उस समय सूचक की स्थिति उस समय होती है जब कोई इसे देखता है।

@ Matthias247 मुझे नहीं लगता कि आपको इस बात की गारंटी है कि P::Target का पता स्थिर है अगर P: Unpin ? मैं हालांकि इस बारे में गलत हो सकता है?

@ Matthias247

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

क्या आप स्पष्ट कर सकते हैं कि आपका इससे क्या मतलब है? T: Unpin आप निम्नलिखित लिख सकते हैं:

let pin_t: Pin<&mut T> = ...
let mut other_t: T = ...
mem::replace(Pin::get_mut(pin_t), &mut other_t);
// Now the value originally behind pin_t is in other_t

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

लेटेस्ट बिकेशडिंग:

• Unpin : MoveFromPin बारे में क्या? यदि मैं अभी भी कुछ सूक्ष्मताओं को याद नहीं कर रहा हूं, तो मुझे लगता है कि यह सीधे बताता है कि विशेषता वास्तव में किस क्षमता को सक्षम बनाती है: यदि प्रकार Pin , तो भी आप इसे स्थानांतरित कर सकते हैं।

  गंभीर रूप से यह उसी तरह का कहता है जैसे Unpin , लेकिन एक सकारात्मक दावे के रूप में तैयार किया जाता है, इसलिए डबल-नकारात्मक !Unpin बजाय अब हमारे पास !MoveFromPin । मुझे लगता है कि मुझे लगता है कि व्याख्या करना आसान है, कम से कम ... यह उह है, प्रकार आप एक पिन से बाहर नहीं जा सकते।

  (मूल विचार में भिन्नता के लिए कुछ जगह है: MoveOutOfPin , MoveFromPinned , MoveWhenPinned , और इसी तरह।)

• Pinned : यह तब NoMoveFromPin , और इसका प्रभाव !MoveFromPin टाइप करना है। मुझे लगता है कि काफी सीधा लगता है।

• Pin खुद: यह एक अन्य दो से जुड़ा हुआ है और उतना महत्वपूर्ण भी नहीं है, लेकिन मुझे लगता है कि यहां कुछ मामूली सुधार के लिए भी जगह हो सकती है।

  मुद्दा यह है कि Pin<&mut T> (उदाहरण के लिए) का अर्थ यह नहीं है कि &mut को पिन किया गया है, इसका मतलब है कि T है (एक भ्रम है जो मुझे लगता है कि मैंने देखा है) कम से कम एक हालिया टिप्पणी सबूत)। चूंकि Pin हिस्सा &mut पर एक प्रकार के संशोधक के रूप में कार्य करता है, मुझे लगता है कि ऐसा मामला है कि इसे Pinning कहना बेहतर होगा।

  इसके लिए कुछ अप्रत्यक्ष मिसाल है: अगर हम घबराने के बजाय एक पूर्णांक प्रकार के अतिप्रवाह शब्दार्थ को संशोधित करना चाहते हैं, तो हम कहते हैं कि Wrapping<i32> बजाय Wrap<i32> ।

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

पुन :: Repin , मैं इस तरह से कुछ होने की उम्मीद करेंगे

unsafe trait Repin {
    unsafe fn repin(from: *mut Self, to: *mut Self);
}

जिसका उपयोग !Unpin प्रकारों के लिए Vec -समान संग्रह के अंदर किया जा सकता है जो कभी-कभी अपनी सामग्री को स्थानांतरित कर देता है (यह अभी या कभी भी इस तरह के लक्षण जोड़ने का प्रस्ताव नहीं है, बस मेरी पहली छाप है विशेषता नाम)।

इसके अलावा नामों को काटकर:

• Pin<P> -> Pinned<P> : मूल्य सूचक P अंक को जीवन भर के लिए स्मृति में पिन कर दिया जाता है (जब तक गिरा नहीं)।
• Unpin -> Moveable : मूल्य को पिन करने की आवश्यकता नहीं है और स्वतंत्र रूप से चारों ओर ले जाया जा सकता है।
• Pinned (संरचना) -> Unmoveable : Pinned होने की आवश्यकताएं और आसपास नहीं ले जाया जा सकता।

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

हालाँकि, पिछली चर्चा के बाद से Pinned जोड़ा गया था, और मुझे लगता है कि यह PhantomPinned PhantomData तरह अपने प्रेत के प्रकार को स्पष्ट करने के लिए समझ में आता है।

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

यह मेरे अनुभव के पूरी तरह से विपरीत है, मैन्युअल रूप से !Unpin लागू करने का मतलब है कि आप असुरक्षित कोड का उपयोग करते हुए हाथ से एक आत्म-संदर्भित संरचना को लागू कर रहे हैं, एक अत्यंत आला उपयोग मामला। इसके विपरीत, एक संकेतक के पीछे एक संभावित अनपिन संरचना रखने वाली किसी भी चीज का Unpin का सकारात्मक निहितार्थ होता है। उदाहरण के लिए, Unpin std सभी निहितार्थ सकारात्मक हैं।

@woutoutboats क्या आप इन नामों के बारे में पिछली चर्चा का लिंक प्रदान कर सकते हैं, जहाँ तर्क यहाँ दिए गए हैं?

यहाँ एक धागा है, हालांकि यह निश्चित रूप से RFC थ्रेड और ट्रैकिंग मुद्दे पर चर्चा की गई थी https://internals.rust-lang.org/t/naming-pin-anchor-move/6864

(लंगर और पिन नामक इस धागे के प्रकारों को अब Pin<Box<T>> और Pin<&'a mut T> )

क्या अनपिन को अकल्पनीय के रूप में पढ़ा जाना चाहिए? आप के रूप में अकल्पनीय वास्तव में एक पिन के अंदर है, भले ही मूल्य पिन नहीं रख सकते। (क्या यह भी मेरी ओर से एक सही समझ है?)

मैंने कुछ डॉक्स और टिप्पणी थ्रेड्स के माध्यम से देखा है और विशेष रूप से अकल्पनीय के लिए कोई संदर्भ नहीं देखा है।

अनपिन को किसी भी चीज के लिए छोटा नहीं माना जाता है। एक चीज जो मुझे लगता है कि बहुत से उपयोगकर्ताओं के लिए स्पष्ट नहीं है, लेकिन यह सच है, मानक पुस्तकालय शैली गाइड है कि क्रियाओं को पसंद के नाम के रूप में पसंद किया जाए, विशेषण नहीं - इसलिए Send , Sendable । यह सही स्थिरता के साथ लागू नहीं किया गया है, लेकिन यह आदर्श है। Unpin "अनपिन करने के लिए" के रूप में है, क्योंकि इसमें Pin इस प्रकार से अनपिन करना संभव है जिसे आपने इसे पिन किया है।

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

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

यह इसके लिए कम नहीं हो सकता है, लेकिन यह ठीक है कि मैंने इसे कैसे पढ़ा। चूंकि लक्षण क्रिया हैं, इसलिए आपको मैन्युअल रूप से इसे एक विशेषण में बदलना होगा यदि आप इसका उपयोग किसी प्रकार के ऑपरेशन के बजाय एक प्रकार का वर्णन करने के लिए करना चाहते हैं; std::iter::Iterator , कुछ है कि iterable है द्वारा कार्यान्वित किया जाता std::io::Seek , कुछ है कि seekable है द्वारा कार्यान्वित किया जाता std::pin::Unpin कुछ है कि unpinnable है द्वारा कार्यान्वित किया जाता।

@woutoutboats किसी भी विशिष्ट समस्या के साथ कुछ अन्य नामों के साथ क्रिया की समस्या नहीं है, जैसे Escape या EscapePin ? माना जाता है कि यह चर्चा पहले भी हो चुकी है, लेकिन संभवतः अभी इस पर बहुत अधिक निगाहें हैं, इसलिए मुझे यकीन नहीं है कि यह पूरी तरह से निरर्थक है ...

मुझे लगता है कि एक बात सच है कि यह दुर्भाग्यपूर्ण है कि Pin और Unpin एक जोड़ी के रूप में पढ़ा जा सकता है (कुछ प्रकार "पिन" हैं और कुछ "अनपिन" हैं), जब Pin को संज्ञा माना जाता है, क्रिया नहीं। तथ्य यह है कि Pin एक विशेषता नहीं है उम्मीद है कि चीजों को स्पष्ट करता है। Pinning पक्ष में तर्क समझ में आता है, लेकिन यहां हम नाम की लंबाई की समस्या के खिलाफ भागते हैं। विशेष रूप से चूंकि विधि रिसीवरों को self दो बार दोहराना होगा, हम बहुत सारे पात्रों के साथ समाप्त होते हैं: self: Pinning<&mut Self> । आश्वस्त नहीं है कि Pinning<P> Pin<P> से अधिक स्पष्टता के लायक पूरे चार वर्ण हैं।

@tikue "एस्केप" शब्दावली मुझे लगता है कि भागने के विश्लेषण की तरह अवधारणाओं के साथ परस्पर विरोधी है, मुझे लगता है कि पिनिंग की तुलना में बहुत अधिक अतिभारित है।

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

यह मुझे गलत तरीके से रगड़ता है - क्या समुदाय की अनुभव रिपोर्ट अवांछित है? मैंने व्यक्तिगत रूप से Unpin साथ एक स्पष्ट मुद्दा नहीं देखा था जब तक कि इस थ्रेड में कुछ अन्य टिप्पणियां, साथ ही Pinned डबल नकारात्मक के साथ juxtaposition।

जंग भागने का विश्लेषण नहीं करती है, इसलिए मुझे यकीन नहीं है कि मैं इसे एक वास्तविक मुद्दा मानता हूं।

: घंटी: यह अब ऊपर की अपनी अंतिम टिप्पणी अवधि में प्रवेश कर रहा है । : घंटी:

मैं अभी भी दस्तावेज़ीकरण सुधारों को इस भूमि से पहले https://github.com/rust-lang/rust/issues/55766#issuecomment-438316891 में उल्लिखित देखना चाहता हूँ :)

मैंने ऊपर दिए गए प्रलेखन को जोड़ने के लिए https://github.com/rust-lang/rust/pull/55992 को खोला है और Pinned से PhantomPinned नाम बदला है।

मुझे लगता है कि Pinned (और PhantomPinned ) एक "पिन किए गए" मूल्य को वैचारिक रूप से प्रोत्साहित करते हैं जो Pin बाहर नहीं जा सकता है, जिसका अर्थ है कि Pin में कई मान Unpin ) "पिन" नहीं हैं!

यह भ्रामक लगता है। मुझे Pin में सभी मूल्यों की अवधारणा करना आसान लगता है, जबकि वे Pin , और चाहे पिन किया जा रहा हो या नहीं, स्थायी रूप से Pinned नाम वाली चीज़ है। Pin* से अलग एक नाम दो अलग अवधारणाओं के संगम को रोक देगा।

PhantomNotUnpin : P

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

धन्यवाद! मैं काफी समय से Unpin से परेशान हो रहा हूं, बॉट पिन-पॉइंट (हेह) क्यों नहीं कर पा रहा है। अब मुझे लगता है कि मैं समझता हूं: यह दोहरा-नकार है।

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

यह केवल कार्यान्वयन के बारे में नहीं है, चर्चा के बारे में भी है। impl !Sync काफी दुर्लभ है (अकेले नहीं है क्योंकि यह अस्थिर है), लेकिन Sync और !Sync प्रकारों के बारे में बात करना काफी सामान्य है। इसी तरह, !Unpin इस फीचर की चर्चाओं में काफी ऊपर आ गए, कम से कम मेरे पास जो थे।

मैं भी कुछ ऐसा पसंद करूंगा जो सकारात्मक रूप से एक संपत्ति ( MoveFromPin या तो) व्यक्त करता है। मैं पूरी तरह से एर्गोनॉमिक्स से आश्वस्त नहीं हूं, क्योंकि Pin विपरीत इस विशेषता को बहुत बार लिखना चाहिए।

जंग भागने का विश्लेषण नहीं करती है, इसलिए मुझे यकीन नहीं है कि मैं इसे एक वास्तविक मुद्दा मानता हूं।

LLVM करता है, इसलिए एस्केप विश्लेषण अभी भी Rust के लिए काफी प्रासंगिक है।

इसे हल करने का तरीका उन शब्दों को चुनना है जो Pin / Unpin का अर्थ उल्टा करते हैं। जैसे, Unpin से Relocate नाम बदलें। तब !Unpin !Relocate हो जाता है। यह मेरे लिए कहीं अधिक सहज ज्ञान युक्त है - मैंने इसे "ओह, इस प्रकार की वस्तुओं को स्थानांतरित नहीं किया जा सकता है" के रूप में पढ़ा। एक और दावेदार Movable ।

मुझे यकीन नहीं है कि विपरीत शब्द क्या है जो Pin जगह ले सकता है, या यदि हमें आवश्यकता भी हो। लेकिन मैं निश्चित रूप से डॉक्स के बारे में कुछ ऐसा कह सकता हूं:

एक पिन की गई वस्तु को सीधे DerefMut माध्यम से संशोधित किया जा सकता है यदि और केवल यदि वस्तु को मेमोरी में स्थानांतरित किया जा सकता है। Relocate एक स्वचालित विशेषता है - यह डिफ़ॉल्ट रूप से जोड़ा जाता है। लेकिन अगर आपके मूल्यों को रखने वाली मेमोरी के लिए सीधा संकेत होगा, तो Relocate करके impl !Relocate अपने प्रकार पर जोड़ दें।

impl<T: Relocate> DerefMut for Pin<T> { ... }

यह Unpin तुलना में मेरे लिए कहीं अधिक सहज ज्ञान युक्त है।

मैंने ऊपर सुझाए गए दस्तावेज़ को जोड़ने के लिए # 55992 खोला है

यह केवल https://github.com/rust-lang/rust/issues/55766#issuecomment -438316891 में सुझाए गए भाग को जोड़ता है।

मुझे MoveFromPin सुझाव पसंद है। Relocate भी अच्छा है, लेकिन शायद Pin पर्याप्त के साथ संबद्ध नहीं है। कोई इसे फिर से एक गैर-चल प्रकार के रूप में समझ सकता है (जो ऐसा नहीं है)। RelocateFromPin फिर से अच्छा होगा।

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

जब तक यह स्पष्टता में मदद करता है तब तक मैं किसी भी मुद्दे को लंबे नामों के साथ नहीं देखता हूं।

FWIW मैं एक वोट में फेंकने के साथ-साथ Unpin का कुछ "सकारात्मक" नाम बदलना चाहूंगा जैसे Relocate या MoveFromPin (या इससे भी अधिक शब्द लेकिन शायद थोड़ा अधिक सटीक MayMoveFromPin )।

मैं मानता हूं कि !Unpin या सिर्फ Unpin का नकारात्मक ऋण मेरे लिए ऐतिहासिक रूप से भ्रमित करने वाला रहा है, और एक सकारात्मक "में फंसाया गया कुछ" Pin अंदर होने के बावजूद चल सकता है "मुझे लगता है कुछ भ्रम को कम करने में मदद करेगा!

FWIW मैं शुरू में Unpin बारे में एक ही बात सोचता था, लेकिन जब मैं वास्तव में इसका उपयोग करने के लिए चला गया IMO यह समझ में आता है - यह वास्तव में एक डबल नकार नहीं है, क्योंकि आप जिस ऑपरेशन की तलाश कर रहे हैं वह Unpin की क्षमता है Pin नहीं एक पिन में चीजों को रखने के लिए क्षमता स्वतंत्र रूप से)। यह MoveFromPin , बस अलग-अलग शब्दों में। मैं एक ऐसा नाम पसंद करूंगा, जो लोगों को यह न समझे कि यह " Pin " या कुछ और नहीं है, लेकिन IMO MoveFromPin और अन्य बहुत दूर की बात है। UndoPin ? ( FreePin हैसेल भीड़ के लिए?)

मुझे अभी भी लगता है कि !Unpin अजीब पढ़ता है - मैंने अपनी आंतरिक आवाज़ को और अधिक व्यवहार करने के लिए प्रशिक्षित किया है जैसे "इसे अनपिन न करें!" सामान्य के बजाय " Unpin लागू नहीं करता है", लेकिन इसने कुछ प्रयास किया है।

!Pluck बारे में क्या?

@runiq

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

मैंने अपनी पूर्व टिप्पणी में इसका उल्लेख किया है, लेकिन मुझे लगता है कि यह वास्तव में यह कहने का एक अच्छा तरीका है: Unpin इसे Pin<C<_>> अंदर और बाहर ले जाने का संचालन है। चीजें जो Unpin लागू नहीं करती हैं, वे क्षमता प्रदान नहीं करती हैं।

@ क्रामर्टज मुझे UndoPin काफी पसंद है

@cramertj मैं सहमत हूं कि मैं अब तक प्रस्तावित विकल्पों का बहुत बड़ा प्रशंसक नहीं हूं, लेकिन मैं व्यक्तिगत रूप से वर्डी MoveFromPin Unpin से अधिक का समर्थन करूंगा। यह एक अच्छी बात है कि यह एक डबल-नकारात्मक नहीं है, लेकिन इसे पढ़ने पर (जैसा कि किसी ने इसके साथ एक टन अभी तक काम नहीं किया है) यह मुझे तीन गुना करता रहता है कि यह एक डबल नकारात्मक है। मैं "अन" उपसर्ग को नकारात्मक के रूप में पढ़ने की कोशिश कर रहा हूं ...

मैं उत्सुक हूं, लेकिन @cramertj या दूसरों को क्या आपको ऐसा लगता है कि Unpin बाउंड एर्गोनॉमिकली ऊपर आने पर कितना अच्छा हैंडल है? क्या यह सुपर दुर्लभ है? क्या यह सुपर आम है? यदि दर्द टाइप करने के लिए आम है तो दर्द होना आम है?

एक छोटे-से-मीठे नाम के लिए, मैं व्यक्तिगत रूप से Relocate विचार पसंद करता हूं, लेकिन लंबे समय तक और वर्डियर-लेकिन-ठीक है, क्योंकि-आप-नहीं-टाइप-इट-एज़-जैसा कि मुझे MoveFromPin पसंद है Unpin से बेहतर हैं

मैं उत्सुक हूं, लेकिन @cramertj या दूसरों को क्या आपको ऐसा लगता है कि अनपिन बंधे हुए एर्गोनोमिक रूप से कितना अच्छा है? क्या यह सुपर दुर्लभ है? क्या यह सुपर आम है? यदि दर्द टाइप करने के लिए आम है तो दर्द होना आम है?

मेरे अनुभव में, दो मामले हैं जहां Unpin वास्तव में उपयोगकर्ता कोड में दिखाई देते हैं:

1. Unpin सीमाएँ ऊपर आती हैं क्योंकि आपको वास्तव में एक भविष्य को स्थानांतरित करने की आवश्यकता होती है क्योंकि आप इसे चुनते हैं (उदाहरण के लिए कुछ चुनिंदा एपीआई जैसे सामान)।
2. अधिक सामान्य रूप से, यदि आपका भविष्य केवल भविष्य के अलावा किसी अन्य चीज़ पर सामान्य है, तो आप आम तौर पर Unpin का बिना शर्त कार्यान्वयन जोड़ना चाहते हैं, क्योंकि इससे कोई फर्क नहीं पड़ता कि वे अन्य प्रकार Unpin क्योंकि आप कभी नहीं। उन्हें पिन परियोजना।

दूसरे मामले का एक उदाहरण है यदि आपके पास किसी प्रकार के बफर प्रकार हैं तो आप सामान्य से अधिक हैं (जैसे T: AsRef<[u8]> )। आपको इसमें से टुकड़ा निकालने के लिए पिन करने की आवश्यकता नहीं है, इसलिए आप परवाह नहीं करते हैं कि क्या यह Unpin लागू होता है या नहीं, इसलिए आप बस अपने प्रकार को बिना शर्त लागू करना चाहते हैं Unpin ताकि आप इसे लागू कर सकें Future पिनिंग को अनदेखा करना।

Unpin एक सीमा के रूप में देखने के लिए बहुत आम है - select! , StreamExt::next और अन्य कॉम्बिनेटर सभी को उस प्रकार की आवश्यकता होती है जो वे Unpin होने के लिए संचालित करते हैं।

@withoutboats मैं आपकी बात के लिए उत्सुक हूँ 2 वहाँ; क्या हमें लगता है कि impl Unpin कुछ ऐसा है जिसे लोगों को अक्सर लागू करने के लिए याद रखना पड़ता है? इसी तरह पुस्तकालय लेखक आज अक्सर अपने कस्टम प्रकारों के लिए #[derive(Debug)] या impl std::error::Error भूल जाते हैं, जिससे उन पुस्तकालयों का उपयोग करना कठिन हो जाता है?

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

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

@alexcrichton मैं उत्सुक हूं, लेकिन @cramertj या अन्य क्या आपको ऐसा लगता है कि अनपिन बाउंड एर्गोनोमिक रूप से कितना अच्छा है, इस पर एक अच्छा हैंडल है? क्या यह सुपर दुर्लभ है? क्या यह सुपर आम है? यदि दर्द टाइप करने के लिए आम है तो दर्द होना आम है?

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

अधिकांश समय आपको Unpin बारे में चिंता करने की आवश्यकता नहीं है, क्योंकि Unpin लगभग सभी प्रकारों के लिए स्वतः-कार्यान्वित होता है।

तो केवल Unpin बारे में चिंता करने की आवश्यकता है:

1. आपके पास एक प्रकार है जो अन्य प्रकारों पर सामान्य है (जैसे struct Foo<A> )।

2. और आप उस प्रकार के लिए एक पिनिंग एपीआई (जैसे Future / Stream / Signal ) लागू करना चाहते हैं।

उस मामले में आपको इसका उपयोग करने की आवश्यकता है:

impl<A> Unpin for Foo<A> where A: Unpin {}

या यह:

impl<A> Unpin for Foo<A> {}

impl<A> Future for Foo<A> where A: Unpin { ... }

यह आमतौर पर एकमात्र स्थिति है जहां Unpin की आवश्यकता होती है। जैसा कि आप देख सकते हैं, कि आमतौर पर Unpin ~ 2 बार प्रति प्रकार का उपयोग करने की आवश्यकता होती है।

गैर-संयोजनकर्ताओं के मामले में, या Future / Stream / Signal लागू न करने के मामले में, आपको Unpin का उपयोग करने की आवश्यकता नहीं है

तो मैं कहूंगा कि Unpin बहुत कम ही मिलता है, और यह वास्तव में Future / Stream / Signal कॉम्बिनेटर बनाने की स्थिति में आता है।

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

मुझे लगता है कि दुर्लभ स्थितियों में कुछ पात्रों को बचाने की तुलना में संज्ञानात्मक लाभ (दोहरे नकार से बचना) अधिक महत्वपूर्ण हैं।

खासकर क्योंकि पिनिंग पहले से ही समझने में काफी कठिन है! तो चलिए इसे अनावश्यक रूप से कठिन नहीं बनाते हैं।

@ जोंहू हमें लगता है कि impl Unpin कुछ ऐसा है जो लोगों को अक्सर लागू करने के लिए याद रखना होगा? इसी तरह पुस्तकालय लेखक आज अक्सर अपने कस्टम प्रकारों के लिए #[derive(Debug)] या impl std::error::Error भूल जाते हैं, जिससे उन पुस्तकालयों का उपयोग करना कठिन हो जाता है?

मुझे नहीं लगता कि impl Unpin को भूलना संभव है, क्योंकि अगर लेखक भूल जाता है, तो उन्हें एक कंपाइलर त्रुटि मिलेगी, जो उनके टोकरे को पहले स्थान पर प्रकाशित होने से रोकता है। तो यह #[derive(Debug)] बिल्कुल भी पसंद नहीं है।

जिस स्थिति के बारे में @withoutboats बात कर रहा है वह केवल Future / Stream / Signal कॉम्बिनेटरों को लागू करने वाले लोगों के लिए है, यह किसी और को प्रभावित नहीं करता है (विशेष रूप से, यह प्रभावित नहीं करता है) पुस्तकालय के डाउनस्ट्रीम उपयोगकर्ता)।

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

मुझे लगता है कि आप सही @cramertj हैं , यह वास्तव में सामान्य अर्थों में दोहरा नकार नहीं है, लेकिन @alexcrichton और @glaebhoerl की तरह मैं इसके द्वारा को नकारना है।

@withoutboats मैं आपकी बात के लिए उत्सुक हूँ 2 वहाँ; क्या हम सोचते हैं कि अंपिन एक ऐसी चीज है जिसे लोगों को अक्सर लागू करने के लिए याद रखना पड़ता है? आज के लाइब्रेरी लेखकों के समान ही अक्सर # [व्युत्पन्न (डिबग)] या impl std :: error :: त्रुटि को उनके कस्टम प्रकारों के लिए भूल जाते हैं, जिससे उन पुस्तकालयों का उपयोग करना कठिन हो जाता है?

बिलकुल नहीं! यदि कोई उपयोगकर्ता मैन्युअल रूप से Future कर रहा है जो कि गैर-भविष्य में सामान्य है, तो वे शायद असुरक्षित कोड लिखे बिना अपने भविष्य के कार्यान्वयन में राज्य को बदलना चाहते हैं - अर्थात Pin<&mut Self> का इलाज करना &mut self । उन्हें यह संकेत मिलता है कि MyFuture<T: AsRef<[u8]>> Unpin लागू नहीं होता है। इस समस्या का सबसे अच्छा समाधान तब Unpin । लेकिन इसका एकमात्र प्रभाव उपयोगकर्ता पर Future लागू करने की कोशिश कर रहा है, और इसके लिए उन्हें भूलना असंभव है क्योंकि उनका कोड संकलित नहीं होगा।

@Withoutboats जिस स्थिति की बात कर रहा है, वह केवल Future / Stream / Signal combinators को लागू करने वाले लोगों के लिए है, यह किसी और को प्रभावित नहीं करता है (विशेष रूप से, यह लाइब्रेरी के डाउनस्ट्रीम उपयोगकर्ताओं को प्रभावित नहीं करता है)।

मैं विशेष रूप से नॉन-कॉम्बिनेटर जेनेरिक मैनुअल फ्यूचर्स के बारे में बात कर रहा हूं, जिसमें सिर्फ Unpin का कंबल होना चाहिए, भले ही उनके जेनेरिक Unpin ।

मैंने प्रश्न के लिए एक फ्लोचार्ट बनाया "जब मैं एक मैनुअल भविष्य / स्ट्रीम को लागू कर रहा हूं तो मैं पिनिंग के बारे में क्या करूं?"

थोड़ा और अधिक बिकने के लिए, आज दोपहर के भोजन में मैं LeavePin साथ आया। यह निहित भ्रामक शब्दार्थ के बिना escape के समान स्वर वहन करती है।

क्या प्रत्यारोपित और पिन के बीच कोई दिलचस्प बातचीत है, जैसा कि जीवनकाल के साथ है?

ट्रैकिंग विशेषांक "" चर्चा करता है, लेकिन यह निर्णायक नहीं है। पिन आरएफसी या विशेषज्ञता आरएफसी को इस बातचीत का स्पष्ट रूप से उल्लेख करना चाहिए, या तो "इसे ठीक होना सत्यापित है" या "इसे सुरक्षित रखने के लिए और अधिक शोध की आवश्यकता है"।

@ इवी न केवल साउंडनेस इंटरैक्शन होना संभव नहीं पीरियड है , क्योंकि कोई भी यूजर आज इस लाइब्रेरी कोड को लिख सकता है और यह ठीक संकलन करेगा।

यदि इस लाइब्रेरी कोड के सामने कोई भाषा फीचर मौजूद नहीं है, तो यह अनसाउंड पीरियड है, क्योंकि कोई भी यूजर आज इस लाइब्रेरी कोड को लिख सकता है और यह ठीक संकलन करेगा।

ऐसा नहीं है कि pin पर इसका कोई असर होना चाहिए ... लेकिन मुझे नहीं लगता कि यह लगभग उतना सरल है।

यदि एक लाइब्रेरी सुविधा, जब unsafe का उपयोग कर रही है, तब भाषा का निर्माण कर रही है जिसका व्यवहार अभी तक अनिर्दिष्ट है (जैसे &packed.field as *const _ , या ABI के बारे में विभिन्न धारणाएँ बनाना) तो यदि अतिरिक्त भाषा मान्यताओं को अमान्य कर देती है। उन पुस्तकालयों के बाद मैं सोचता हूँ कि यह पुस्तकालय ही हैं जो अस्वाभाविक हैं न कि भाषा बदलती है। दूसरी ओर, यदि भाषा परिवर्तन परिभाषित व्यवहार को निराधार बनाते हैं तो यह भाषा के परिवर्तनों का दोष है। इस प्रकार संकलित जुर्माना असुरक्षित और भाषा परिवर्तन के मामले में एक पुस्तकालय की आवाज़ के लिए पर्याप्त स्थिति नहीं है।

MoveFromPin या समान के लिए +1

यदि आप प्रश्न पूछते हैं "मुझे अपने प्रकार के लिए अनपिन को कब लागू करना चाहिए?", तो उत्तर बहुत अधिक स्पष्ट है यदि आप पूछते हैं कि "मुझे अपने प्रकार के लिए MoveFromPin को कब लागू करना चाहिए?"

उसी के साथ "क्या मुझे अनपिन को यहां बंधी विशेषता के रूप में जोड़ना चाहिए?" बनाम "क्या मुझे मूवमेंट बाउंड के रूप में मूवफ्रेमपिन जोड़ना चाहिए?"

पिनिंग नहीं है! हटो

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

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

अंतिम टिप्पणी की अवधि, ऊपर की विलय करने के पूरी हो चुकी है ।

अनपिन के नामकरण के आसपास एक अनसुलझी चिंता होनी चाहिए।

जैसा कि @RalfJung ने बताया , # 55992 भी केवल https://github.com/rust-lang/rust/issues/55766#issuecomment -438316891 और अन्य जगहों पर पूछे गए अतिरिक्त दस्तावेज़ों की एक छोटी राशि जोड़ता है। नहीं पता है कि अभी तक विलय नहीं करने के लिए आधार है।

क्यों मेरी ड्रॉप () विधि अब फिर से और पिन के बजाय, स्वयं को ले जाती है।

खैर, ड्रॉप () पुराना है - यह रुस्ट 1.0 से मौजूद है - इसलिए हम इसे बदल नहीं सकते हैं। हम इसे सिर्फ पिन <और म्यूट सेल्फ> लेना पसंद करेंगे, और फिर अनपिन प्रकार अपने & म्यूट प्राप्त कर सकते हैं जैसे वे अब करते हैं, लेकिन यह एक गैर-बैकवर्ड-संगत परिवर्तन है।

मैं सोच रहा था कि क्या इस बदलाव को पिछड़े संगत तरीके से लागू करना संभव होगा। AIUI जब तक हम Unpin जोड़ते हैं (और लोग !Unpin निर्दिष्ट कर सकते हैं) सभी प्रकार Unpin । इसलिए हम एक विशेषता जोड़ सकते हैं:

trait DropPinned {
    fn drop(Pin<&mut> self);
}

और फिर सभी Unpin प्रकारों के लिए इस विशेषता को निहित करें, जब तक कि लोग ऑप्ट आउट नहीं कर सकते सभी प्रकार हैं। कुछ इस तरह:

impl<T> PinDrop for T where T:Unpin + Drop {
    fn drop(Pin<&mut T> self) {
        Drop::drop(self.get_mut());
    }
}

फिर हम करने के लिए कॉल डालने संकलक होगा DropPinned::drop के बजाय Drop::drop । अनिवार्य रूप से DropPinned Drop बजाय लंग-आइटम बन जाता है। AFAICS यह पिछड़ा संगत होगा यदि और केवल इस तंत्र को Unpin रूप में पेश किया गया था।

अनपिन के नामकरण के आसपास एक अनसुलझी चिंता होनी चाहिए।

@tikue किसी भी Unpin बारे में कोई भी तर्क नया या नया नहीं लगा, इसलिए आमतौर पर हमारी प्रक्रिया वर्तमान पर विचार करेगी। नामकरण को अंतिम रूप दिया जाना है। जाहिर है अगर किसी को चिंता है तो उन्हें बोलना चाहिए, लेकिन टीम चेकबॉक्स होने के बाद FCP का मतलब यह सुनिश्चित करना है कि हर कोई एपीआई के रूप में प्रस्तावित प्रस्तावित को स्थिर कर रहा है।

@cramertj मैं थोड़ा भ्रमित हूँ। कई लोगों ने बात की है। जब मैंने संदर्भों के लिए पूछा कि Unpin के नामकरण के बारे में और तर्क कहाँ से उठाए गए और हल किए गए, तो मुझे https://internals.rust-lang.org/t/naming-pin-anchor- पर बताया गया भी देख सकते हैं के रूप में के नामकरण के बारे में शिकायत लोगों की है Unpin , और कोई वास्तविक जवाबी तर्क। Https://github.com/rust-lang/rfcs/pull/2349 में मूल RFC के पास इतना औचित्य नहीं है कि क्यों Unpin लिए प्रस्तावित विकल्प खराब हैं। यहां तक ​​कि इस धागे में, यह केवल काउंटर-तर्कों की तरह लगता है जो वास्तव में सामने आते हैं "यह छोटा है" और "यह तकनीकी रूप से सही है"। क्या आप ठोस चर्चा की ओर इशारा करने में सक्षम हैं, जहाँ वैकल्पिक नाम समझने में आसान हैं (जैसे MoveFromPin ) चर्चा और अस्वीकार कर दी जाती है?

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

@tikue मैंने लाया है और दोहरे-नकारात्मक मुद्दे को कई बार देखा है, और Unpin के सटीक नामकरण को कई बार एक मुद्दे के रूप में उठाया गया है और लगातार Unpin पक्ष में हल किया गया है Unpin का नाम शामिल नहीं है Unpin एक अनसुलझे सवाल के रूप में: हमने विकल्पों पर चर्चा की है, और यह FCP निर्णय लेने की प्रक्रिया थी कि हम जो निर्णय किए गए थे, उन्हें Unpin शामिल करने के लिए तैयार किया गया था।

@cramertj क्या आप कृपया एक लिंक प्रदान कर सकते हैं जहां यह चर्चा हुई है? मैं आपको संदेह नहीं कर रहा हूं, मैं Unpin पक्ष में तर्क देखना चाहूंगा, क्योंकि मुझे विश्वास नहीं है कि वे यहां दिए गए हैं। जैसा कि उल्लेख किया गया है, अब तक मुझे दिए गए संदर्भ Unpin के नामकरण पर कोई संकल्प प्रदान नहीं करते हैं।

@cramertj +1 से @jonhoo का पूछना। यदि ऐसी चर्चाएँ हैं कि लिबास टीम आपस में थी जो आधिकारिक चैनलों में पंजीकृत नहीं हैं, तो मुझे लगता है कि उन चर्चाओं का मुख्य जोर यहाँ दोहराया जाना चाहिए। मुझे लगता है कि यहां तक ​​कि एक आधिकारिक नियम भी है कि आरएफसी के निर्णय केवल सार्वजनिक रूप से ज्ञात तर्कों के आधार पर किए जा सकते हैं?

मुझे लगता है कि यहां तक ​​कि एक आधिकारिक नियम भी है कि आरएफसी के निर्णय केवल सार्वजनिक रूप से ज्ञात तर्कों के आधार पर किए जा सकते हैं?

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

@wleyley जो काम नहीं करती है, जैसे impl<T> Drop for Vec<T> टूट जाएगी क्योंकि हमारे पास Vec<T>: Unpin । साथ ही, इस पंक्ति के प्रस्ताव भी इस धागे में पहले भी बनाए जा चुके हैं। कृपया उत्तर देने से पहले चर्चा पढ़ें। मुझे पता है कि यह काफी पूछ रहा है, लेकिन बार-बार समझाया जा रहा है कि एक ही मुद्दे से बचने का एकमात्र तरीका है।

मुझे लगता है कि यहां तक ​​कि एक आधिकारिक नियम भी है कि आरएफसी के निर्णय केवल सार्वजनिक रूप से ज्ञात तर्कों के आधार पर किए जा सकते हैं?

यह अनौपचारिक रूप से "कोई नया तर्क नहीं" नियम के रूप में जाना जाता है।

निश्चित नहीं है कि यह कहाँ पोस्ट किया जाए, लेकिन क्या कोई https://github.com/rust-lang/rust/issues/56256 पर एक नज़र डाल सकता है?

# 56256 से संबंधित, impl<T> From<Box<T>> for Pin<Box<T>> को ओपी में स्थिर होने के रूप में सूचीबद्ध नहीं किया गया है, लेकिन यह एक बार Pin । क्या कोई अन्य विशेषता है जो गैर-तुच्छ है और स्थिरीकरण के लिए देखा जाना चाहिए? (डॉक्स को स्कैन करना अन्य सभी मेरे लिए लिपटे पॉइंटर के लिए तुच्छ प्रतिनिधि कार्यान्वयन को प्रदर्शित करता है)।

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

इसलिए हम अब इसे स्थिर करने के साथ आगे नहीं बढ़ेंगे (FCP भले ही)।

यह बहुत सराहनीय होगा यदि कोई व्यक्ति इस सूत्र में विचारों को इकट्ठा कर सकता है और नामकरण की स्थिति में सुधार के लिए एक स्टैंडअलोन प्रस्ताव तैयार कर सकता है।

@Kimundi

यह बहुत सराहनीय होगा यदि कोई व्यक्ति इस सूत्र में विचारों को इकट्ठा कर सकता है और नामकरण की स्थिति में सुधार के लिए एक स्टैंडअलोन प्रस्ताव तैयार कर सकता है।

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

सहकर्मियों के एक समूह के साथ बिकेशेडेड और DePin सुझाव दिया, जिसे मैं वास्तव में काफी पसंद करता हूं, क्योंकि यह Unpin "पिन नहीं" का अर्थ निकालता है और जोर देता है कि यह एक प्रकार की बात कर रहा है। जो डी Pin 'd हो सकता है।

@ किमुंडी आप या कोई भी व्यक्ति टीम से ले सकता है कृपया इसे स्पष्ट "

@rfcbot चिंता नामकरण-अनपिन

मुझे यकीन नहीं है कि अगर यह वास्तव में एक बार काम करता है FCP दर्ज किया गया है, लेकिन मैं Unpin विशेषता के नामकरण पर एक औपचारिक अवरोधक चिंता करना चाहता हूं। Unpin विशेषता एपीआई के लिए बहुत महत्वपूर्ण लगती है, और "डबल नेगेटिव" (जैसा कि ऊपर चर्चा की गई है) मुझे हर बार पढ़ने के बाद स्पिन के लिए फेंक देता है।

विभिन्न नामों के बारे में टिप्पणियों का एक पूरा गुच्छा रहा है, लेकिन दुर्भाग्य से मैं अभी तक किसी के साथ रोमांचित नहीं हूं। मेरा "पसंदीदा" अभी भी MoveFromPin या Relocate की तर्ज पर है (मेरे भगवान की बहुत सारी टिप्पणियां हैं यहां मुझे पता नहीं है कि यह कैसे समीक्षा करें)।

मैं व्यक्तिगत रूप से Pin के नामकरण के साथ-साथ Pinned एक ZST के लिए है जो Unpin विशेषता को लागू नहीं करता है।

मैं @alexcrichton से पूरी तरह सहमत Unpin का नामकरण यहां विवाद का बड़ा बिंदु है। मुझे नहीं लगता कि जहां तक ​​प्रस्तावित सुविधा के बारे में मैं देख सकता हूं, वहां तक ​​कोई भी तकनीकी चिंता नहीं है (हालांकि _are_ बहुत सारी टिप्पणियां हैं, इसलिए कुछ याद किया जा सकता है)।

मुझे अभी भी लगता है कि Pinned ZST के लिए एक अजीब नाम है , क्योंकि कुछ जिसमें Pinned वास्तव में पिन नहीं किया गया है .. यह सिर्फ Unpin । PhantomPinned (जैसा कि इसे # 55992 में बदल दिया गया है) में एक ही मुद्दा है कि यह Pin को संदर्भित करता है, जब ZST _really_ Unpin ।

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

इसके अलावा, @ किमुंडी , मुझे यह देखकर खुशी हुई कि

@Jonhoo के बारे में Pinned अभी भी अजीब लग रहा है, और PhantomPinned किसी भी बेहतर नहीं होने से सहमत है (यह किसी भी तरह से पिन नहीं किया गया है, यहां तक ​​कि प्रेत तरीके से भी नहीं)। मुझे लगता है कि अगर हम Unpin लिए एक अच्छा नाम पाते हैं, तो Pinned स्वाभाविक रूप से Not{NewNameForUnpin} बदला जा रहा है।

मुझे वास्तव में नहीं लगता कि हमें PhantomPinned चर्चा करते हुए किसी भी अधिक समय बिताने की आवश्यकता है - यह प्रकार लगभग कभी भी अंत उपयोगकर्ताओं को दिखाई PhantomNotUnpin / PhantomNotDePin / PhantomNotMoveFromPin / इत्यादि इसे किसी भी अधिक या कम आम या एपीआई बनाने के लिए उपयोगकर्ताओं को अधिक या कम स्पष्ट नहीं कर रहे हैं जो पहले से ही काफी सहज हैं एपीआई PhantomPinned लिए एक वैध उपयोग के साथ आए हैं।

बस एक त्वरित विचार: Move और ZST Anchor लगाएं।

हर प्रकार Move सक्षम है, जब तक कि इसमें Anchor जो इसे Pin चिपका देता है।
मुझे पसंद है कि कैसे Anchor: !Move सहज रूप से बहुत कुछ समझ में आता है।

मैं सुझाव नहीं दे रहा हूं कि हम विशेष रूप से PhantomPinned पर समय व्यतीत कर रहे हैं, लेकिन मुझे लगता है कि यह खुले दिमाग रखने के लिए कम प्रयास होगा, क्योंकि यह संभव है कि जो कुछ भी Unpin लिए उतरा है वह काम करेगा साथ ही PhantomPinned ।

हमने Move कवर किया है और बताया कि यह कई बार अनुचित क्यों है। सभी प्रकार के चल रहे हैं जब तक वे pinned हैं। इसी तरह, Anchor पहले भी सुझाया जा चुका है लेकिन यह इस नाम से बिल्कुल भी स्पष्ट नहीं है कि इसका उपयोग Unpin ing / Move ing से किया जाता है।

@stjepang मुझे लगता है कि Move को कुछ समय पहले त्याग दिया गया है क्योंकि !Unpin होना वास्तव में इसे स्थानांतरित होने से नहीं रोकता है। यह केवल तभी होता है जब एक प्रकार Pin अंतर्गत होता है, और यह Unpin , कि आप इसे स्थानांतरित करने के लिए "अनुबंधित" नहीं हैं।

मूल टिप्पणी में @withoutboats ने कहा:

Pin रैपर पॉइंटर को "पिन" करने के लिए संशोधित करता है, जो मेमोरी को संदर्भित करता है

मुझे लगता है कि यह अजीब है कि प्रकार Unpin लागू करते हैं क्योंकि मान "पिन नहीं किए जाते हैं" - स्मृति है। हालांकि, यह उन मूल्यों के बारे में बात करने के लिए समझ में आता है जो "स्थानांतरित करने के लिए सुरक्षित हैं"। अगर हम Unpin से MoveSafe नाम बदल दें तो क्या होगा?

UnwindSafe विशेषता पर विचार करें। यह सिर्फ एक "संकेत" मार्कर विशेषता है और इसे लागू करने के लिए सुरक्षित है। यदि आप एक !UnwindSafe मूल्य catch_unwind सीमा ( AssertUnwindSafe ) पार करते हैं, तो आप इसे अपने चालानों को अमान्य करके "तोड़" देंगे।

इसी तरह, यदि आपके पास !Unpin / !MoveSafe मूल्य है, तो भी इसे (बेशक) स्थानांतरित किया जा सकता है, लेकिन आप इसके स्व-संदर्भों को अमान्य करके इसे "तोड़" देंगे। अवधारणा समान लगती है।

लक्षण Unpin वास्तव में सिर्फ MoveSafe अर्थ है। ऐसा लगता है कि यह उन मूल्यों के बारे में नहीं है जिन्हें Pin पीछे स्मृति से बाहर ले जाया जा सकता है। इसके बजाय, यह उन मानों के बारे में है जो आपको स्थानांतरित करने पर "ब्रेक" नहीं करेंगे।

MoveSafe को Move रूप में एक ही समस्या है - सभी मूल्यों को किसी भी प्रकार सुरक्षित रूप से स्थानांतरित किया जा सकता है। इसे पिन किए जाने के बाद किसी मूल्य को ले जाना असंभव हो जाता है।

MoveSafe को Move रूप में एक ही समस्या है - सभी मूल्यों को किसी भी प्रकार सुरक्षित रूप से स्थानांतरित किया जा सकता है।

ठीक है, लेकिन यह "सुरक्षित" का एक अलग अर्थ है, जैसे UnwindSafe । वैसे भी, मैं Relocate या उस तरह का कुछ भी के साथ ठीक हो जाएगा।

संक्षेप में, मुझे लगता है कि विशेषता नाम DePin नहीं होना चाहिए, Unpin , या इसके नाम में "पिन" के साथ कुछ भी नहीं होना चाहिए। मेरे लिए, यह भ्रम का मुख्य स्रोत है। विशेषता वास्तव में Pin के झोंपड़ियों से "एस्केप हैच" नहीं है - विशेषता कहती है कि मूल्य स्थानांतरित होने पर अमान्य नहीं होगा।

मैं सिर्फ Pin और Unpin को पूरी तरह से अलग चीजों के रूप में देखता हूं। :)

मुझे ठीक इसके विपरीत लगता है;) पिन के संबंध में विशेषता केवल सार्थक है, जो एकमात्र प्रकार है जो हमारे पास है जो अंतर्निहित मूल्य की स्थिरता पर सार्थक रूप से बाधाओं को व्यक्त करता है। पिन के बिना, अनपिन पूरी तरह से अर्थहीन है।

मुझे पिनबोर्ड पर कुछ डालने के बारे में सोचना पसंद है। यदि आप बोर्ड पर पिन की गई वस्तु का पिन निकालते हैं, तो आप ऑब्जेक्ट को स्थानांतरित कर सकते हैं। पिन हटाना अनपिनिंग है।
मुझे नाम Unpin ।

मैं यह भी देख सकता हूं कि अनपिन एक दोहरा नकार है, और भ्रम पैदा कर सकता है। हालांकि, मुझे आश्चर्य है कि आपको कितनी बार !Unpin लिखने की आवश्यकता है।

एक अन्य नाम जो मैं अनपिन के लिए ले सकता हूं वह Detach । पिनबोर्ड रूपक पर वापस, आप _Unpin_ नहीं करेंगे, लेकिन _Detach_ पिन को अपनी वस्तु से।

मुझे लगता है कि मुझे वास्तव में DePin ! अब तक यह मेरा पसंदीदा है - यह संक्षिप्त है, यह स्पष्ट रूप से एक क्रिया है और विशेषण नहीं है, और !DePin बहुत स्पष्ट रूप से स्पष्ट लगता है ("डी-पिन नहीं किया जा सकता")।

मुझे लगता है कि यह अजीब है कि प्रकार अनपिन को लागू करते हैं क्योंकि मान "पिन नहीं" हैं - मेमोरी है।

मान को मेमोरी में पिन किया जाता है। लेकिन मूल्य यहाँ भी महत्वपूर्ण है। मेरे लिए पिनिंग मेमोरी, केवल यह सुनिश्चित करने के बारे में है कि यह निष्क्रिय या ऐसा ही रहता है, लेकिन mem::swap द्वारा इसका उल्लंघन नहीं किया जाता है। मेमोरी के लिए एक मूल्य पिन करना उस पिन किए गए मूल्य को कहीं और नहीं ले जाने के बारे में है, जो कि वास्तव में Pin है।

मैं यह भी देख सकता हूं कि अनपिन एक दोहरा नकार है, और भ्रम पैदा कर सकता है। हालाँकि, मुझे आश्चर्य है कि आपको कितनी बार लिखने की आवश्यकता है!

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

मेरे पास कोड नहीं है, लेकिन पहली बार मैंने वायदा का उपयोग करने की कोशिश की, मैं एक impl Future<Output=T> वापस करने के लिए एक फ़ंक्शन चाहता था। मुझे याद नहीं है कि क्या हुआ था, लेकिन मुझे तुरंत टी और अनपिन के बारे में शिकायत करने वाली एक गंभीर संकलक त्रुटि मिली। जिस प्रश्न के लिए मुझे एक उत्तर की आवश्यकता थी, "क्या यह केवल टी अनपिन होने के लिए टी को विवश करने के लिए सुरक्षित है"। और इसने मुझे लगभग 2 कष्टप्रद घंटों के लिए रसातल में धकेल दिया।

"ओह, ठीक है तो क्या पिन का मतलब है। तो अनपिन का मतलब है .. बॉक्स? क्यों एक विशेषता है?"

"रुको, impl !Unpin ? क्यों impl Pin ?"

"सही, पिन और अनपिन ... विपरीत नहीं हैं। वे पूरी तरह से अलग चीजें हैं। रुको, फिर अनपिन का फिर से क्या मतलब है? इसे क्यों कहा जाता है?"

"पृथ्वी पर क्या !Unpin मतलब है? नहीं ... दूसरे, पिन बात नहीं? Hrrrgh"

फिर भी यह मेरे दिमाग में एकमात्र तरीका है जो 'अनपिन' को 'रिलोकेबल' के साथ बदल देता है। "टाइप मेमोरी में स्थानांतरित नहीं होता है" पूर्ण अर्थ बनाता है। और फिर भी ,

Unpin से Relocatable (या Relocate ) का नाम बदलने से मेरा वोट 4 हो जाता है। लेकिन मुझे अनपिन से बेहतर किसी भी अन्य सुझाव के बारे में पता चलेगा।

पिन के संबंध में विशेषता केवल सार्थक है, जो एकमात्र प्रकार है जो हमारे पास है जो अंतर्निहित मूल्य की स्थिरता पर सार्थक रूप से बाधाओं को व्यक्त करता है। पिन के बिना, अनपिन पूरी तरह से अर्थहीन है।

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

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

अनपिन विशेष रूप से उन प्रकार के व्यवहारों के बारे में है जो टाइप किए जाने के बाद सुरक्षित होने का दावा किया जाता है (अर्थात्, इसे स्थानांतरित करना), प्रकार की कुछ आंतरिक संपत्ति के बारे में नहीं।

जब व्यवहार किया जाता है , तो यह साझा किए जाने पर व्यवहार / अपरिवर्तनीय की तरह, आंतरिक प्रकार की संपत्ति होती है। मैं इस ब्लॉग पोस्ट में बहुत अधिक विस्तार से गया।

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

आह, हाँ, तो मैं सहमत हूँ। एक !DePin प्रकार हमेशा पिन नहीं किया जाता है, और जब यह नहीं होता है, तो इसे किसी अन्य प्रकार की तरह स्थानांतरित किया जा सकता है।

@cramertj @withoutboats एक बात जो मैं अभी तक नहीं कर पाया हूं, क्या आप Unpin नाम बदलने के खिलाफ हैं? ऐसा नहीं लगता कि आप ऐसा महसूस करते हैं कि आप सहमत हैं कि इसका नाम बदलने की आवश्यकता है, लेकिन मुझे यकीन नहीं है कि आप इसके खिलाफ हैं।

मुझे व्यक्तिगत रूप से नहीं लगता है कि यहाँ मुख्य समस्या Unpin और "अगर हम इसका नाम बदल सकते हैं तो यह सब कुछ सहज होगा"। नाम बदलने में थोड़ी मदद मिल सकती है (और Relocate / DePin यहां अच्छा लगता है ...), मुझे लगता है कि मुख्य जटिलता खुद को पिन करने की अवधारणा से आती है; यह निश्चित रूप से समझने या समझाने के लिए सबसे आसान अवधारणाओं में से एक नहीं है; लगभग भी नहीं।

इसलिए, मुझे लगता है कि core::pin मॉड्यूल के दस्तावेज़ीकरण को _significantly_ और बहुत अधिक उदाहरणों को शामिल करने की आवश्यकता है। अच्छे उदाहरण दोनों ही कैनोनिकल उपयोग के मामलों के साथ-साथ असुरक्षित कार्यों और कार्यान्वयनों के उपयोग को दर्शाते हैं जो कि निराधार हैं।

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

मेरा वोट std::pin::Reloc (स्थानांतरित) है

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

Unpin यह दर्शाता है कि यह सभी T (जहां T: Unpin ) से संक्रमण के लिए तुच्छ है, जबकि पिन किए गए प्रकार की स्थिति में है (मुझे उम्मीद है कि मैं सही ढंग से इस शब्द को याद कर रहा हूं) @RalfJung के ब्लॉग पोस्टों में से एक से) पिन-रहित टाइप-स्टेट नहीं है। यही कारण है कि Pin &mut T हाथ कर सकते हैं।

तो चलिए मान लेते हैं कि मैं एक प्रकार का Woof बनाना चाहता हूं, जिसके लिए हमेशा Woof के सभी राज्यों से संक्रमण करना संभव है, जबकि पिन किए गए प्रकार-राज्य में पिन किए गए प्रकार के लिए नहीं- राज्य, लेकिन ऐसा करना तुच्छ नहीं है और इसके लिए Unpin लागू नहीं किया जा सकता है, क्या Woof लिए fn unpin(self: Pin<Box<Woof>>) -> Box<Woof> जैसे कार्य करने की अनुमति होगी?

एक प्रकार के Meow लिए समान है जिसके लिए केवल कभी-कभी पिन किए गए से पिन-टू-पिन और fn unpin(self: Pin<Box<Meow>>) -> Result<Box<Meow>, Pin<Box<Meow>>> जैसे फ़ंक्शन से संक्रमण संभव है।

बिकेशिंग के लिए मेरे 2 सेंट:

अगर मैं सही ढंग से समझूं, तो क्या Unpin मतलब है " Pin का मुझ पर कोई प्रभाव नहीं है"।

BypassPin या IgnorePin जैसी किसी चीज़ के बारे में क्या?

तो चलिए मान लेते हैं कि मैं एक प्रकार का Woof बनाना चाहता हूँ जिसके लिए यह हमेशा संभव है कि Woof के सभी राज्यों से संक्रमण हो, जबकि पिन किए गए टाइप-स्टेट में पिन-टाइप टाइप-स्टेट नहीं है, लेकिन ऐसा करना तुच्छ नहीं है क्या अनपिन को लागू नहीं किया जा सकता है, क्या यह Woof के लिए fn अनपिन (स्वयं: पिन) की तरह एक कार्य करने की अनुमति होगी>) -> बॉक्स?

हाँ, यह संभव होना चाहिए। उदाहरण के लिए, यदि Woof एक घुसपैठ से जुड़ी सूची का एक तत्व है, तो यह सूची से तत्व को निकालने के लिए एक फ़ंक्शन प्रदान कर सकता है, और एक ही समय में Pin को निकाल सकता है (यह तर्क देते हुए कि गैर के लिए Woof s, दोनों टाइपस्टेट्स समतुल्य हैं, इसलिए हम इसे डी-पिन कर सकते हैं)।

Relocate पास RePin रूप में एक ही मुद्दा है, यह एक ऑपरेशन को एक पिन किए गए स्थान से दूसरे स्थान पर स्थानांतरित करने की अनुमति दे सकता है, न कि मूल्य को पूरी तरह से अनपिन करते हुए। यह RePin की तुलना में कम मजबूत अर्थ है, लेकिन अभी भी थोड़ा भ्रमित लगता है।

यह एक ऑपरेशन को एक पिन किए गए स्थान से दूसरे में मान को स्थानांतरित करने की अनुमति दे सकता है, न कि पूरी तरह से मूल्य को अनपिन करता है।

हालांकि यह बिल्कुल नहीं है कि यह विशेषता क्या है, यह पूरी तरह से गलत भी नहीं है: अधिकांश उपयोग-मामलों के लिए, एक पिन किए गए स्थान से दूसरे स्थान पर एक मान को स्थानांतरित करना उतना ही भयावह है जितना कि इसे स्वतंत्र रूप से उपयोग करना। वास्तव में, यह देखते हुए कि कोई भी Pin<Box<T>> , मैं यह भी नहीं देखता कि आप यहां एक मौलिक अंतर क्यों बना रहे हैं।

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

हां, यही कारण है कि उस ऑपरेशन को एक प्रकार में जोड़ने वाला गुण उपयोगी हो सकता है (यह Unpin तरह मार्कर विशेषता नहीं हो सकता है क्योंकि इसे अपडेट आंतरिक संदर्भ जैसी चीजें करने की आवश्यकता हो सकती है)। मैं प्रस्ताव नहीं कर रहा हूं कि हम अभी कुछ इस तरह से जोड़ते हैं, बस यह कुछ ऐसा है जिसे मैं भविष्य में प्रदान किया जा सकता है (या तो std या तृतीय पक्ष में) जो नामों के एक भ्रमित ओवरलैप के साथ समाप्त हो सकता है।

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

ठीक है तो यहाँ कुछ सोच रहा है। मैं शुरू में सोच रहा था कि क्या हमारा नाम PinInert या PinNoGuarantees जैसा कि वर्णन भी है, लेकिन इस बारे में सोचकर कि मैं वास्तव में क्या चाहता हूं, एक वर्णन के विपरीत एक कार्रवाई का वर्णन करने वाला एक लक्षण है संपत्ति, या कम से कम यह मेरे सिर के बारे में सोचने के लिए बहुत आसान बनाता है।

Unpin (मुझे यकीन नहीं है) के साथ एक समस्या यह है कि मैं इसे अपने सिर के माध्यम से प्राप्त नहीं कर सकता है, जिसका अर्थ है कि "पिन से निकालने की क्रिया, अनपिनिंग, करना सुरक्षित है "। लक्षण के रूप में "अनपिनिंग की कार्रवाई" का खुलासा किया है, लेकिन जब मैं इसे पढ़ता हूं, तो मैं काफी समझ में नहीं आ सकता है। Pin<T: Unpin> होना अजीब लगता है क्योंकि अगर यह "अनपिन" है तो यह पिन में क्यों है?

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

( Can का उपसर्ग होने से क्रिया को मुझे और भी आसानी से पता चलता है, और यह कहती है कि आप इसे पिन से हटा सकते हैं लेकिन आप हमेशा आवश्यक नहीं हैं)।

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

क्या ये ऑपरेशन आमतौर पर उन्हें लगाने के लिए जोखिम भरे स्थान को सही ठहराने के लिए पर्याप्त होते हैं? (स्वाभाविक रूप से) या क्या वे शायद ही कभी पर्याप्त रूप से उपयोग किए जाते हैं कि संबंधित कार्यों का सुरक्षित मार्ग पेट हो सकता है?

चूँकि मेरे पास इस खेल में स्पष्ट रूप से अब त्वचा है: CanUnpin मुझे Unpinnable या कुछ इसी तरह से आत्मा के बहुत करीब लगता है, और मेरी धारणा हमेशा से रही है कि समुदाय उन प्रकार के संशोधक में शामिल है लक्षण नाम, चूंकि अधिकांश लक्षण उस क्रिया का वर्णन करते हैं जो प्रकार ले सकता है। निहितार्थ उस अर्थ में "निहित" या "-योग्य" है। जो कुछ भी तय किया गया है (और नाम उस सीमा तक मायने नहीं रखता है, यहां IM-not-so-HO - बहुत कम उपयोगकर्ताओं को यह टाइप करने की संभावना होगी), मैं सभी को यहां प्रश्नों को हल करने के बारे में कुछ आग्रह महसूस करने के लिए प्रोत्साहित करूंगा। मैं इस स्थिरीकरण के लिए उत्साहित हूं, और मुझे पता है कि बहुत से लोग हैं!

@alexcrichton

Unpin (मुझे यकीन नहीं हो रहा है) के साथ एक समस्या यह है कि मैं इसे अपने सिर के माध्यम से प्राप्त नहीं कर सकता है, जिसका अर्थ है "पिन से हटाने की क्रिया, अनपिनिंग, करना सुरक्षित है "।

क्या होगा अगर आप T: Unpin को " T Pin " के लिए प्रतिरक्षा मानते हैं? फिर अगर आपके पास Pin<T: Unpin> तो इसका मतलब है कि हमें Pin अंदर एक मूल्य मिला है, जो कि पिनिंग करने के लिए प्रतिरक्षा है इसलिए यहाँ प्रभावी रूप से लूट है।

या दूसरे शब्दों में: Unpin Pin बेअसर करता है । सच कहूं, तो बहुत चर्चा के बाद मैंने इस तरह का आंतरिककरण किया है और अब यह समझ में आता है। 😆

इसमें से बहुत कुछ एक तरह से या किसी अन्य गारंटी के बारे में नहीं है ( Unpin लागू करने का मतलब यह नहीं है कि आप इसे एक पिन से हटा देंगे, इसका मतलब है कि आप _can_ इसे पिन से हटा देंगे)।

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

@anp मैं सहमत हूं कि CanUnpin एक महान नाम नहीं है, मैं एक बेहतर नाम का पता लगाने के लिए अपने सबसे अच्छे काम करने का प्रयास कर रहा हूं! ऐसा लगता है कि अभी भी कुछ लोगों को लगता है कि इसका नाम बदला जाना चाहिए, हालांकि जैसा कि सभी सुझावों के लिए मूल रूप से एक ही कारण के लिए शॉट लगता है, मुझे लगता है कि Unpin पहली जगह में नाम बदलने की जरूरत है।

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

@stjepang I ने भी, इतना सोचने के बाद अब Unpin कर लिया है! इस बिंदु पर सभी वैकल्पिक नाम काफी कम लगते हैं, इसलिए मैं उस बिंदु पर पहुंच रहा हूं जहां मैं बेहतर प्रलेखन के लिए व्यवस्थित हो जाऊंगा। मैं आदर्श रूप से किसी ऐसे व्यक्ति को ढूंढना चाहूंगा जो Pin एपिस के बारे में बहुत कुछ नहीं जानता हो, बाद में कहा कि प्रलेखन को पढ़ने के लिए, हालांकि, यह जांचने के लिए पर्याप्त है।

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

@rfcbot चिंता में सुधार-प्रलेखन

मुझे लगता है कि बेहतर प्रलेखन की आवश्यकता क्या है:

• प्रत्येक विधि पर अधिक गद्य क्यों सुरक्षित है और / या यह असुरक्षित क्यों है। उदाहरण के लिए P DerefMut क्रियान्वयन "उचित व्यवहार करना" Pin::new_unchecked पर प्रलेखित नहीं है।
• प्रत्येक unsafe फ़ंक्शन का एक कोड उदाहरण होना चाहिए कि यह असुरक्षित क्यों है, या कम से कम चरणों के अनुक्रम की स्पष्ट व्याख्या जो गलत हो सकती है।
• मुझे लगता है कि मॉड्यूल डॉक्स अधिक विस्तार में जा सकते हैं बस एक Pin क्या है और इसका क्या मतलब है। मुझे लगता है कि उन्हें "कैसे यह सामान्य अचल प्रकार नहीं है, लेकिन इसका एक रूप है" या "कैसे Pin व्यवहार में उपयोग किया जाता है, उदाहरण के लिए वायदा के साथ" जैसी जानकारी से लाभ होगा।
• मैं या तो दस्तावेज़ों या कोड उदाहरणों में जेनरिक और Unpin साथ एक उदाहरण देखना चाहता हूं। उदाहरण के लिए, ऐसा लगता है कि वायदा में कई कॉम्बिनेटरों को इसे संभालना है, और इसी तरह कुछ कॉम्बिनेटरों को विशेष रूप से इसकी आवश्यकता होती है । कुछ उदाहरण ऐसे मामलों का उपयोग करते हैं कि कोई कैसे जेनरिक के साथ काम करता है और वे कैसे खेलते हैं Unpin काफी समझने में मदद मिल सकती है।

अगर अन्य लोगों के पास भी ठोस कार्रवाई योग्य चीजें हैं, तो मुझे भी उत्सुकता होगी कि मैं भी दस्तावेज में जोड़ दूं!

आगे मैं self साथ as_ref self -फॉर्म पर औपचारिक रूप से ब्लॉक करना चाहूंगा, लेकिन मुझे संदेह है कि यह हल करने के लिए जल्दी होगा। (फिर से इसे जल्दी लाने के लिए याद नहीं करने के लिए खेद है)

@rfcbot को स्व-तरीकों की चिंता है

यह as_ref , as_mut , get_ref , get_mut , into_ref , और set सभी पर तरीके होने का प्रस्ताव है। Pin प्रकार। इस प्रस्ताव में उल्लेख किया गया है कि हम विधि की गड़बड़ी के कारण स्मार्ट पॉइंटर्स के लिए ऐसा नहीं करते हैं, लेकिन यह अनुभव करते हैं कि अनुभव आज के लागू Pin API के अनुरूप नहीं है और यह अक्सर बस रास्ते में हो जाता है।

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

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

और जब मैं उस पर हूँ, एक आखिरी चीज़ जो मैंने देखी है, और फिर से मुझे लगता है कि यह हल करने के लिए बहुत जल्दी होगा

@rfcbot चिंता बॉक्स-पिन-बनाम-बॉक्स-पिन

नाम है Box::pin के लिए विचार किया गया Box::pinned ? Pinned और / या PhantomPinned के अस्तित्व के साथ ऐसा लगता है जैसे यह नाम वापसी के प्रकार से मेल खा सकता है!

@alexcrichton ने कुछ भी विशेष रूप से MoveFromPin विकल्प के रूप "नाम जो पूरे वाक्यांश हैं ... बहुत ही अनिश्चित होंगे" (@withoutboats) और यह "अभी तक बहुत चिंताजनक" है @cramertj)।

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

अनुभवी उपयोगकर्ताओं (जो हम सभी हैं!) के बारे में आकस्मिक रूप से विशेषाधिकार प्राप्त करने वाले अन्य लोगों के बारे में जो फ्रेशर दिमाग के साथ चीजों पर आ रहे हैं, यह एक तरह की गलती है जो मुझे लगता है कि हमें बनाने के प्रति कभी भी सतर्क रहने की जरूरत है, जितना कठिन है ।

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

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

@valff वास्तव में यह सही है, हालांकि काफी लोग ऐसे हैं जिन्होंने डॉक्स पढ़े हैं और समझते हैं कि पिनिंग कैसे काम करती है, फिर भी Unpin नाम अभी भी उन्हें महत्वपूर्ण मानसिक कठिनाई का कारण बनता है, जबकि अन्य नाम कम होते हैं।

@glaebhoerl ओह स्पष्ट करने के लिए क्षमा करें, मैं व्यक्तिगत रूप से MoveFromPin या CanUnpin वर्तमान Unpin के एक प्रशंसक से अधिक हूं। बस एक निष्कर्ष पर जाने में मदद करने की कोशिश कर रहा है!

मैंने वर्तमान प्रस्ताव को समझने की कोशिश की, हो सकता है कि इस प्रकार की प्रगति रिपोर्ट नामकरण पर कुछ अतिरिक्त प्रकाश डाल सके।

• Pin की गारंटी को स्थिर पते पर Drop बढ़ाना Pin के निर्माता पर अतिरिक्त आवश्यकताएं डालता है। मुझे यह उपयोगी लगा होगा यदि unsafe fn new_unchecked(pointer: P) -> Pin<P> को लागू करने के लिए उन आवश्यक पूर्व शर्तो का सीधे उल्लेख किया गया हो। एक Pin कैसे बनाया जा सकता है, यह समझने में उनकी अवधारणा को समझने में बेहद मदद करता है।
• ट्रैकिंग मुद्दे में उल्लेखित सारांश, we agreed that we are ready to stabilize them with no major API changes. साथ पूर्ववर्ती है, जिसमें बहुत सारी पुरानी एपीआई हैं। इसी समय, इसमें Drop और पिन प्रोजेक्शन के बारे में बहुत अधिक अंतर्दृष्टि है जो प्रासंगिक है। इसमें बुलेट बिंदु एक में निर्दिष्ट अतिरिक्त गारंटी का एक स्पष्ट सूत्रीकरण भी शामिल है जो इस रिपोर्ट में नहीं पाया गया है। पुरानी और ताज़ा जानकारी का यह मिश्रण थोड़ा भ्रमित करने वाला था, इस मुद्दे में सभी जानकारी को स्थानांतरित करने या आउटडेटेड पैराग्राफ का संकेत देने पर विचार करें।
• चूंकि अतिरिक्त गारंटी को slight extension रूप में संदर्भित किया जाता है, Unpin पहले करने के लिए सोचा था, लेकिन मुझे लगता है कि Unpin वास्तव में थोड़ा मजबूत है। यह कहता है कि पिन किए गए राज्य को स्वतंत्र रूप से एक असंपीड़ित राज्य में बदल दिया जा सकता है। यह ठीक है कि वर्तमान इंटरफ़ेस इस संबंध में न्यूनतम है, लेकिन Unpin को उस प्रकार के ऑपरेशन से भ्रमित किया जा सकता है जो कुछ आंतरिक आक्रमण को दूर करता है जिसके लिए पिन राज्य की आवश्यकता होती है (जैसे Drop एक नरम संस्करण) ।

स्पष्टता: मैं व्यक्तिगत रूप से अन्य नामों पर MoveFromPin पक्ष लेता हूं, लेकिन यह यकीनन कृत्रिम और स्पष्ट है।

पहले से ही @alexcrichton द्वारा अनुरोध किए गए दस्तावेज़ीकरण सुधारों के अलावा, मन में आने वाली प्रमुख ठोस कार्रवाई योग्य आइटम map_unchecked और map_unchecked_mut में पिन प्रक्षेपण के लिए फ़ील्ड नियम के पीछे के कारण को समझाएगी । की तर्ज पर कुछ:

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

ऑटो व्युत्पन्न मार्कर विशेषता के लिए ElidePin नाम के बारे में क्या?

यह कैप्चर करेगा कि प्रकार को हमेशा के रूप में माना जा सकता है या ऐसा व्यवहार कर सकता है जैसे कि वह अनपिन किया गया हो। और !ElidePin रूप में अच्छी तरह से स्पष्ट है, हालांकि यह व्यक्तिपरक हो सकता है।

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

MoveFromUnpin / RemoveFromUnpin लिए मेरा सामान्य विरोध सिर्फ इतना है कि वे बहुत चिंतित हैं और मैनुअल Future कार्यान्वयन के एर्गोनॉमिक्स को फिर से प्राप्त करेंगे। CanUnpin / DePin दोनों ठीक me-- को मैं चाहता हूँ इसे और अधिक स्पष्ट कर दिया कि था प्रतीत Unpin की पद्धति का अनुसरण Read / Write /आदि। लेकिन ऐसा लगता है कि यह लोगों के लिए सहज नहीं है, इसलिए मैं +1 कुछ भी कर सकता हूं जो सिंटैक्टिक नमक की तरह दिखने के बिना यह स्पष्ट करता है।

मैं सहमत हूं कि NotWhateverUnpinBecomes शायद Pinned लिए सबसे अच्छा नाम है। उस ने कहा, Adhere अर्थ दोनों को ध्यान में रखना और चिपकना है। : Slightly_smiling_face:

CanUnpin / DePin दोनों ही मुझे ठीक लगते हैं - काश यह अधिक स्पष्ट होता कि Unpin रीड / राइटिंग आदि के पैटर्न का अनुसरण करता।

मुझे लगता है कि Unpin विपरीत Read Unpin हार्ड बनाने वाली चीजों में से एक यह है कि यह एक मार्कर विशेषता है। Read समझना आसान है क्योंकि एक तरीका Read::read - आपको जो कुछ भी जानना है वह trait में वहीं है। यदि x Read मैं समझता हूं कि मैं x.read() - write Write लिए कॉल कर सकता हूं, आदि यह समझाना कठिन है कि X Unpin लागू करने का मतलब है कि Pin<Ptr<X>> DerefMut - जिसका अर्थ है कि आप इसका इलाज कर सकते हैं जैसे कि यह सिर्फ X ।

पढ़ने को समझना आसान है क्योंकि एक विधि है :: पढ़ें

यदि केवल हम auto trait परिभाषाओं / GATs में हमेशा लागू होने वाले तरीकों को जोड़ सकते हैं, तो हम Unpin::unpin - fn unpin<P: DerefFamily>(self: Pin<P::Deref<Self>>) -> P::Deref<Self> )। ..... दूसरे विचार पर, मुझे नहीं लगता कि यह किसी को कम भ्रमित करने वाला है;)

(अधिक गंभीर नोट पर, मैं Pin::unpin Pin<P<T>> से P<T> जाने के लिए समर्थन करूँगा)

मैं पिन का समर्थन करता हूँ :: पिन से जाने के लिए अनपिन

> से पी

यह मेरे सिर में दो शब्दों को भ्रमित करता है, ठीक वर्तमान नाम की तरह। unpin बहुत प्रकार की राज्य की गारंटी को उलटने जैसा लगता है, तुलना के लिए ऐसा होगा जैसे कि एक विधि fn unborrow(&'_ T) या fn unmove(??) । चूँकि pin गारंटी प्रदान करती है जब तक कि किसी प्रकार का प्रतिनिधित्व करने वाली मेमोरी Drop::drop एड न हो, हम वास्तव में राज्य को उल्टा नहीं करते हैं, प्रकार केवल गारंटी देता है कि अन्य सभी प्रतिनिधित्व बराबर गारंटी को बनाए रखते हैं और हम इस प्रकार इसे अनदेखा कर सकते हैं । यह भी मुख्य अंतर है जो मैं मार्कर लक्षण और io::Read जैसे कुछ के बीच देखता हूं। एक संकलक या भाषा के लिए संचालन को सक्षम करता है, जबकि दूसरा प्रोग्रामर के लिए संचालन को सक्षम करता है।

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

अंत में, मुझे लगता है कि कम्प्यूटेशनल काम के साथ unpin फ़ंक्शन वाले प्रकारों के लिए संभावित है। एक विशेष प्रकार के आंतरिक इनवेरिएंट के साथ एक प्रकार इस तरह से अपनी आंतरिक स्थिति को 'ठीक' करने में सक्षम हो सकता है कि यह एक इंटरफ़ेस fn unpin(self: Pin<&'a mut T>) -> &'a mut पेशकश कर सकता है, जहां यह जीवन भर के लिए Pin की सभी गारंटी को जब्त कर लेता है। 'a । उस स्थिति में, उपरोक्त दोनों बिंदु अब लागू नहीं होते हैं। इस तरह के एक समारोह में कल्पना की जा सकती है जैसे कि एक ही मेमोरी लोकेशन में ड्रॉपिंग और पुनर्निर्माण करने के लिए समान प्रभाव पड़ता है (इस प्रकार वास्तव में प्रकार राज्य को हटा रहा है)। और इसमें संगणना शामिल हो सकती है, जैसे कुछ आत्म संदर्भों को गतिशील आवंटन में स्थानांतरित करना।

यह दुर्भाग्यपूर्ण होगा अगर एक भ्रमित नाम भी इन दो विचारों को भ्रमित करके गैर-भ्रमित नामों को चुनने के लिए पुस्तकालय डिजाइनरों और कार्यान्वयनकर्ताओं के लिए कठिन बना देगा।

MoveFromUnpin / RemoveFromUnpin के लिए मेरा सामान्य विरोध सिर्फ इतना है कि वे बहुत अधिक चिंतित हैं और मैन्युअल भविष्य के कार्यान्वयन के एर्गोनॉमिक्स को पुनः प्राप्त करेंगे।

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

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

@rfcbot नामकरण-अनपिन को हल करता है

ठीक है, मैं थोड़ी देर के लिए टहल रहा हूं और इस बारे में व्यक्तिगत रूप से हूं । मैं चारों ओर आया हूँ कि अब मैं कम से कम Unpin साथ मार्कर विशेषता के रूप में व्यक्तिगत रूप से सहज हूं। नतीजतन, मैं एक अवरुद्ध आपत्ति को दूर करने जा रहा हूं (हालांकि यदि लिबास टीम के अन्य लोग अलग तरह से महसूस करते हैं, तो कृपया हमें बताएं!)

मुख्य कारण है कि मैं Unpin आसपास आया हूं मूल रूप से @cramertj ने जो Unpin (या कम से कम मेरी राय में) तक रहता है।

जबकि मुझे अभी भी विश्वास है कि "मैंने अभी-अभी इस विशेषता का नाम देखा है और मैं यह जानना चाहता हूं कि यह क्या करता है" के लिए बेहतर नाम हैं, मुझे नहीं लगता कि यहां हल करने के लिए सही समस्या है। यह इस बिंदु पर मेरे लिए स्पष्ट है कि हम इस समय कम से कम, इस विशेषता के लिए एक अलग नाम का पता नहीं लगा सकते हैं, जो कि मुहावरेदार भी है , लेकिन इसके बजाय हम एक अलग समस्या को हल करने वाले विशेषता नामों पर स्विच कर रहे हैं। Unpin को समझना Send और Sync , प्रलेखन को पूरी तरह से समझने के लिए पढ़ने की आवश्यकता है कि क्या चल रहा है।

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

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

यहाँ "मुहावरेदार" का क्या अर्थ है? Reloc[ate] , Escape , Evade , Pluck , या Roam बारे में क्या एकतरफा है? वे सभी क्रियाएं हैं, और उनमें से कोई भी दोहरे नकारात्मक समस्या होने के लिए गलत नहीं हो सकता है।

@alexcrichton क्या एक कारण है कि Unpin को Depin या DePin से अधिक मुहावरेदार माना जाता है?

मुझे लगता है कि Depin बहुत ठोस विकल्प है, और यह मुझे Unpin के समान मानसिक कठिनाइयों का कारण नहीं बनता है।

एक साधारण कारण यह हो सकता है कि डिपिन एक शब्द नहीं है और अनपिन है। निजी तौर पर, मुझे Unpin समझने में कोई परेशानी नहीं है। मुझे लगता है कि यह अन्य मार्कर लक्षणों के नामकरण के साथ फिट बैठता है।

@jimmycuadra Rust में बहुत सारे नाम हैं जो "वास्तविक" शब्द नहीं हैं, जिसमें stdlib भी शामिल है।

मुझे आश्चर्य होगा कि अगर एक दूसरे पर एक नाम चुनने का एक महत्वपूर्ण कारण माना जाता था।

@Pauan यह एक महत्वपूर्ण कारण है। एक देशी अंग्रेजी बोलने वाले के रूप में, Depin मुझे लगता है कि हम भूल गए कि अनपिनिंग के लिए शब्द मौजूद है और एक को बनाने की कोशिश की। यह मुझे गंभीर रूप से गलत लगता है: अंग्रेजी शब्द "डेपिनिंग" "अनपिनिंग" है।

एक अच्छा सादृश्य होगा यदि हमारे पास एपीआई थे जो "अनलॉक" के बजाय "डेलॉक" कहते थे।

"मुहावरेदार" द्वारा @jaredr का मतलब है कि मैं मानक पुस्तकालय के स्थापित सम्मेलनों का अनुसरण कर रहा हूं जो पहले (जैसे पहले उल्लेख किए गए) Read और Write लक्षण हैं। हमारे पास नॉन-वर्डी-नामों, क्रियाओं, जहां संभव हो, और स्थिति के लिए उपयुक्त का एक सम्मेलन है।

आपके द्वारा सुझाए गए नाम जैसे सभी संभव हैं, लेकिन Unpin (या इसलिए मुझे कम से कम लगता है) इस विशेष कार्रवाई के लिए सबसे उपयुक्त है ("आप इस प्रकार को अनपिन कर सकते हैं" गारंटी)। अन्य, Unpin ढीले समानार्थी शब्द, मुझे लगता है कि बड़े पैमाने पर केवल "अनपिन" शब्द से नाम बदल रहे हैं और कभी-कभी Pin Unpin साथ एक ही संबंध नहीं देते हैं। कर देता है।

@Pauan मैं हूं कि Depin आवाज़ नहीं आती है, क्योंकि यह Unpin ।

@aturon ने https://github.com/rust-lang/rfcs/pull/2592#issuecomment -438873636 में उल्लेख किया है कि:

Pin का उपयोग &self बनाम &mut self की पसंद की तुलना में कार्यान्वयन विवरण का अधिक नहीं है; लंबे समय में, यह संभावना है कि Pin स्वयं भाषा समर्थन के साथ संदर्भ का एक अलग मोड होगा। इन सभी मामलों में, हस्ताक्षर में जो बताया जा रहा है, वह Pin , इस अनुमति को संदर्भ से बाहर जाने से मना किया जा रहा है।

मूल रूप से यह एक मूल &pin या कुछ और ... को संदर्भित करता है, लेकिन यह कैसे Pin<&mut T> और इस तरह से वर्ग करता है। @Withoutboats और विशेष रूप से @cramertj के साथ मेरी बातचीत में, वे भाषा समर्थन के साथ संदर्भ के एक अलग तरीके के विचार के बारे में बिल्कुल सुनिश्चित नहीं थे और हम Pin<T> से वहां कैसे पहुंच सकते हैं।

pin स्थिर करने से पहले, यह सुनिश्चित करना समझदारी होगी कि हम एक ही पृष्ठ पर हैं। बुनियादी ढांचे का यह महत्वपूर्ण टुकड़ा; तो मैं मुख्य रूप से हारून के लिए इस पर और नौकाओं और टेलर के लिए विस्तार करना चाहूंगा।

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

@alexcrichton यह वास्तव में एक अच्छी बात है, मुझे लगता है? जैसे Send को स्थानांतरित करने / कॉपी (=) संचालन करने के लिए, Sync उधार (और) ऑपरेशन के लिए। शायद इस तरह के कनेक्शन वास्तव में अधिक भ्रम पैदा कर रहे हैं?

@ crlf0710 यह हो सकता है! मुझे यकीन नहीं है कि मैं खुद इस तरह के कनेक्शन से सहमत हूं। Send और Sync इस बात के बारे में अधिक हैं कि वे क्या सक्षम कर रहे हैं ("थ्रेड को अन्य प्रकारों के लिए टाइप करें" और "सिंक करें" थ्रेड्स तक पहुँच प्राप्त कर रहे हैं), और उनका नामकरण करते समय हमने कोशिश नहीं की एक ऑपरेशन या किसी अन्य के नामकरण से बचें

@alexcrichton बिल्कुल! तो शायद यह विशेषता यह भी होनी चाहिए कि यह क्या सक्षम कर रहा है। ( "चलती (एक क्रिया यहाँ) एक Pin । मैं मूल अंग्रेजी वक्ता नहीं हूं, लेकिन मुझे अभी भी लगता है कि pin से "अनपिनिंग" थोड़ा ... अजीब है?

@ crlf0710 लेकिन क्या गुण सक्षम करता है, पिन से <moving> नहीं है, इसका <moving out of a Pin> । चाल के लिए और पर्यायवाची के साथ समस्या यह है कि वे स्पष्ट रूप से लक्षण को स्थानांतरित करने की क्षमता को नियंत्रित करते हैं, जो यह नहीं करता है। पिन का कनेक्शन यह समझने के लिए महत्वपूर्ण है कि विशेषता वास्तव में क्या करती है।

तो इस विशेषता के लिए सबसे मुहावरेदार नाम एक क्रिया होगी जिसका अर्थ है "एक पिन से बाहर निकलने के लिए," जिसके लिए "अनपिन" शब्द मेरे लिए बहुत स्पष्ट है। यहाँ विक्षनरी की परिभाषा "अनपिन" है:

1. एक पिन को हटाने के द्वारा unfasten करने के लिए।
2. (सकर्मक, कंप्यूटिंग, ग्राफिकल यूजर इंटरफेस) उस जगह से अलग करना (एक आइकन, एप्लिकेशन आदि) जहां इसे पहले पिन किया गया था।

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

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

उसी समय कृपया मुझे अपना अंतिम सुझाव देने की अनुमति दें: वास्तव में मुझे लगता है कि Detach ऊपर उल्लिखित क्रिया भी काफी अच्छी है, हालांकि थोड़ी बहुत सामान्य है। जैसा कि मैंने कहा, मैं देशी वक्ता नहीं हूं, इसलिए मैं दूसरों के लिए नहीं बोल सकता। कृपया इसे थोड़ा विचार के रूप में देखें।

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

pin_proj! { let MyStruct { field1, field2 } = a_pinned_mutable_reference; }

खेतों में पिन किए गए परस्पर संदर्भों में Pin<&mut MyStruct> को विघटित करना।

इसे सुरक्षित और उपयोगी बनाने के लिए, हमें दो अन्य चीजों की आवश्यकता होगी:

• Kite प्रकार "हमेशा- Unpin " फ़ील्ड को चिह्नित करने के लिए
• Unpin असुरक्षित बनाओ

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

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

@qnighy अपने Drop कार्यान्वयन में गारंटियों की गारंटी के उल्लंघन के लिए एक प्रकार के लिए संभव है, जो Drop बराबर Unpin लिए शक्तिशाली बनाता है। Unpin असुरक्षित किसी भी अतिरिक्त कोड को सुरक्षित नहीं बनाता है, क्योंकि Drop भी सुरक्षित है, और इसे बदला नहीं जा सकता है। हमने ट्रैकिंग के मुद्दे पर इस बारे में बहुत बात की है, और इसका उल्लेख इस धागे पर भी किया गया है।

मौलिक रूप से, पिन अनुमानों को कुछ नकारात्मक सीमाओं को मुखर करने की क्षमता के बिना सुरक्षित नहीं बनाया जा सकता है जो आज रस्ट में व्यक्त नहीं किए जा सकते हैं।

@ crlf0710

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

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

@withoutboats इस बिकेशेड में किसी भी नाम या ज्यादा निवेश के लिए मेरी कोई खास पसंद नहीं है ... लेकिन मैं उत्सुक हूं; क्या अन्य उद्देश्य Detach फिट होगा (यदि आप अटकलें लगाते हैं ...)?

@ केंद्र में मेरे पास स्पष्ट उपयोग का मामला नहीं है, लेकिन मैं उदाहरण के लिए विनाशकारी से संबंधित कुछ उपयोग मामले की कल्पना कर सकता हूं।

@withoutboats हाँ जो समझ में आता है; चियर्स!

@withoutboats मैं नहीं यकीन है कि अगर विक्षनरी प्रविष्टि सबसे अच्छा प्रेरणा का नामकरण का औचित्य साबित करने के लिए है हूँ Unpin सक्षम करने के लिए move from a pin । भौतिक प्रतिनिधित्व रूपक इस तथ्य से पीड़ित हैं कि जंग में चलना दुनिया में एक वस्तु को दूर नहीं ले जा रहा है। अधिक सटीक होने के लिए, एक पिन किए गए पॉइंटर को 'upinning' करने से मुझे संदर्भित मेमोरी पर नियंत्रण नहीं मिलता है, यह आवंटन और वैधता है, जो कि T ऑब्जेक्ट प्रतिनिधित्व के रूप में है। T का नियंत्रित प्रतिनिधित्व नहीं देता है, जैसा कि अनबॉक्सिंग होगा। और, unpinning के संदर्भ में moving को परिभाषित करने वाली एक शब्दकोश प्रविष्टि वास्तव में इस तरह के नाम के औचित्य से अधिक भ्रम का हिस्सा है।

प्रस्तावित एपीआई में, विधियों में से किसी का भी ऐसा प्रभाव नहीं है (और यह पिन के दायरे में भी नहीं है)। मुझे Pin<Box<T>> से Box<T> (और T ) का संक्रमण करने के लिए उदाहरण के लिए कोई सुरक्षित रास्ता दिखाई नहीं देता है और न ही मुझे यकीन है कि Unpin चाहिए ऐसी मजबूत संभावनाएं हैं। मुझे बिल्कुल यकीन नहीं है कि सभी अंतर कहां होंगे। लेकिन जहाँ तक मैं समझता था, Pin कुछ मेमोरी लोकेशन पर लागू होता है जबकि Unpin गारंटी देता है कि T s प्रतिनिधित्व में कुछ भी पिन गारंटियों पर निर्भर नहीं करता है। हालाँकि, यह वही होगा जो पूरी तरह से मेमोरी को बाहर निकालने और भूलने में सक्षम है? मुझे नहीं लगता। मैं एक और अधिक ठोस उदाहरण के बारे में सोचूंगा।

संपादित करें: अधिक संक्षेप में, भले ही T Unpin , क्या मैं T::drop(&mut) कुछ उदाहरण पर भरोसा कर सकता हूं जिसे उस मेमोरी पर कॉल किया जा रहा है, इससे पहले कि मेमोरी डीलॉक्लेटेड है? जहां तक ​​मैं औपचारिकता से बता सकता हूं, इसका जवाब हां में होना चाहिए, लेकिन नाम Unpin मेरे विपरीत है।

संपादित करें 2: Rc एक Pin<&T> का निरीक्षण करने की अनुमति देता है, लेकिन T: Unpin अभी भी drop मूल स्मृति स्थान पर नहीं है। पिन के बाहर एक संदर्भ रखें, फिर पिन को गिरा देने के बाद आप Rc::try_unwrap साथ बाहर जा सकते हैं। https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=dec6f6c6d2c0903d87a4a9cefe50a0a प्रभावी रूप से मौजूदा तंत्र के माध्यम से प्रश्न का उत्तर देता है, लेकिन क्या यह उद्देश्य के रूप में काम करता है?

शायद IgnorePin ? तो T है IgnorePin आप का इलाज कर सकते Pin<Box<T>> के रूप में &mut T अनिवार्य रूप से की उपस्थिति की अनदेखी Pin (AIUI भी अनदेखी Box )। उपेक्षा करना एक क्रिया है, मुझे लगता है कि IgnorePin नहीं है, लेकिन मुझे यकीन नहीं है कि यह क्या है। IgnorePin यह क्या अनुमति देता है के बारे में वर्णनात्मक है, यह प्रकार पर रखा बाधाओं का वर्णनात्मक नहीं है, लेकिन न तो Unpin ।

@wleyley मैं एक बहुत ही समान विचार था, ElidePin , ऊपर कुछ टिप्पणी में, हालांकि तब मैं सहमति व्यक्त करने में सक्षम नहीं था कि क्यों एक और अधिक सटीक लगा। लेकिन मैं मानता हूं कि 'एक क्रिया' रस्ट मार्कर लक्षण के लिए स्टाइल गाइड है। भले ही यह !ElidePin / !IgnorePin के रूप में अधिक प्राकृतिक निषेध की अनुमति देता है, लेकिन यह इष्टतम नहीं है।

@withoutboats प्रश्न का अनुसरण करें: चूंकि पिन अंतर्निहित मेमोरी के संदर्भ में निर्दिष्ट है, पिन ZST के साथ कैसे इंटरैक्ट करता है? Pinned ZST होने के कारण, एक ZST Unpin भी हो सकता है या नहीं। मैं सहज रूप से कहूंगा कि इसकी मेमोरी प्रतिनिधित्व कभी भी औपचारिक रूप से अमान्य नहीं है, इस प्रकार T::drop(&mut self) आवश्यकता को कभी भी नहीं बुलाया जा सकता है, काफी समान है कि कोई एक लीक से &mut 'static _ मेमोरी कैसे बना सकता है Box । उसी समय, यह सब गलत हो सकता है और मैं देखता हूं कि एक और व्याख्या कैसे संभव होगी। मुझे लगता है कि इन सेटिंग्स को प्रलेखन में ध्यान देने योग्य है।

बनाने के लिए यह सुरक्षित है एक Pin<P<T>> के साथ एक T: !Unpin और फिर तुरंत मूल्य अनपिन, यह गारंटी है कि अगर कुछ भी नहीं पिन ने कहा कि? क्या यह केवल अपरिभाषित व्यवहार है अगर पिन किए गए मूल्य को स्थानांतरित कर दिया गया है, क्योंकि यह एक पोल-जैसी विधि है जिसे इस पर बुलाया गया है?

@HeroicKatora दुर्भाग्य से, आज Drop को उस प्रकार के लिए लागू करना संभव है, जो जेनेरिक के कारण !Unpin हो सकता है, उदा:

struct S<T>(T); // `!Unpin` if `T: !Unpin`
impl<T> Drop for S<T> { ... }

@cramertj धन्यवाद, बस एहसास हुआ कि के रूप में अच्छी तरह से।

@cramertj तो हम सामान्य सीमा पर T: ?Unpin डिफ़ॉल्ट करते हैं? करने के लिए दोषी नहीं वहाँ एक और कारण के पीछे है T: Unpin मौजूदा तरह प्रकार के लिए Sized ? यह कुछ उदाहरण देता है जहां यह कष्टप्रद रूप से सख्त होगा लेकिन क्या अतिरिक्त ऑटो बाध्य रेजगारी का कारण बन सकता है?

@HeroicKatora को मानक लाइब्रेरी में प्रत्येक प्रकार के ?Unpin सीमा को छिड़कने की आवश्यकता होगी और कोड का एक गुच्छा जिसमें Unpin बिल्कुल भी परवाह नहीं है।

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

टी के लिए डिफ़ॉल्ट न होने के पीछे एक और कारण है: मौजूदा प्रकारों के लिए अनपिन?

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

क्या यह केवल अपरिभाषित व्यवहार है अगर पिन किए गए मूल्य को स्थानांतरित कर दिया गया है, क्योंकि यह एक पोल-जैसी विधि है जिसे इस पर बुलाया गया है?

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

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

@cramertj मैं देख रहा हूं, यह थोड़ा दुर्भाग्यपूर्ण होगा। मैं विनिर्देशन में Pin Drop विनिर्देशन में नहीं बल्कि भाषा के साथ थोड़ा असहज हूं। इंटरफ़ेस शुद्धता, प्रयोज्य और निकट भविष्य में इसे जारी करने के बीच काफी परस्पर विरोधी। क्या मुझे ऊपर दिए गए संपादन 2 पर स्पष्टीकरण मिल सकता है:

आरसी एक को पिन <& T> का निरीक्षण करने की अनुमति देता है, लेकिन टी के लिए: अनपिन के पास अभी भी मूल मेमोरी स्थान पर कॉल ड्रॉप नहीं है। पिन के बाहर एक संदर्भ रखें, फिर पिन को गिरा देने के बाद आप Rc :: try_unwrap के साथ बाहर जा सकते हैं। https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=dec6f6c6d2c0903d87a4a9cefe50a0ca

@HeroicKatora आपके कोड के साथ समस्या यह है कि Mem<'a>: Unpin , लेकिन आपके द्वारा उपयोग किए जाने वाले असुरक्षित कोड की रेखा उन मान्यताओं पर निर्भर करती है जो केवल उन प्रकारों पर लागू होती हैं जो Unpin लागू नहीं होते हैं। मैंने आपके gist को इस बात का सबूत देने के लिए संपादित किया है कि Mem<'a>: Unpin : https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=201d1ae382a590be8c5cac13af279aff

जब आप Pin::new कॉल करते हैं, तो आप अनपिन बाउंड पर भरोसा करते हैं, जिसे केवल उन पॉइंटर्स पर बुलाया जा सकता है, जिनका लक्ष्य Unpin को लागू करता है।

आपके द्वारा पाया गया खामियों पर विचार किया गया है, यही वजह है कि Rc<T: ?Unpin> से Pin<Rc<T>> जाने का कोई तरीका नहीं है। आपको Rc::pinned साथ पिन में Rc का निर्माण करना होगा।

@withoutboats बस इस बात की पुष्टि करना चाहता था, कि T: Unpin वास्तव में अमान्य होने से पहले drop कॉल का विरोध करता है। यह सवाल है, वहाँ भी नहीं होना चाहिए

fn into_inner(Pin<P>) -> P where P: Deref, P::Target: Unpin;

चूँकि यह इंटरफ़ेस के किसी भी भाग की सुरक्षा नहीं करता है, और Pin<Box<T>> को Box<T> जाना संभवतः उपयोगी है ( T: Unpin बेशक)।

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

मैं सिर्फ इतना कहूंगा कि Unpin का नामकरण और कार्यक्षमता दोनों उस काफिले पद्धति के साथ बहुत अधिक कथित अर्थ बनाती है। और यह जानते हुए कि Pin गारंटी वास्तव में T: !Unpin तक ही सीमित है। यह भी इस तरह के एक विधि के अस्तित्व के द्वारा सीधे प्रदर्शित किया जाएगा, बजाय संभावना को दिखाने के लिए भागने के hatches का निर्माण: मुस्कान:। और इसका प्रलेखन प्रतिबंधों को समझाने (या एक बार और लिंक करने) के लिए एक आदर्श स्थान होगा। (एक भी यह नामकरण पर विचार हो सकता unpin के बजाय into_inner )।

संपादित करें: यह ज्यादातर केवल पहले से ही सामान्यीकृत है।

impl<P> Pin<P> where P: Deref, P::Target: Unpin

• fn unpin(self) -> P

P=&'a mut T लिए तात्कालिकता है, जो प्रस्तावित के बराबर है

impl<'a, T: ?Sized> Pin<&'a mut T> where T: Unpin

• fn get_mut(self) -> &'a mut T

अब जब स्थिरीकरण हो गया है, तो PFCP की बात मूक लगती है, इसलिए:

@rfcbot रद्द करें

क्या यह सुनिश्चित करने के लिए कोई ट्रैकिंग है कि https://github.com/rust-lang/rust/issues/55766#issuecomment-437374982 पर शुरू की गई टिप्पणियां डॉक्स में बदल गईं? लगता है कि हम रिलीज के लिए पहले ही बहुत देर हो चुके हैं क्योंकि बीटा बंद हो गया है ... भले ही स्पष्ट रूप से शुरू होने से पहले होने के लिए यहां स्पष्ट रूप से कहा गया था: /

क्या कोई कारण है कि यह अभी भी खुला है? @ केंद्र ने आपको बंद कर दिया और इसे फिर से खोल दिया, क्या वह जानबूझकर था?

@ राल्फजंग मैंने रद्द करने की कोशिश की FCP लेकिन यह नहीं सुना; @alexcrichton क्या आप रद्द कर सकते हैं FCP?

यह स्थिर है, इसलिए बंद है।