संबंधित मुद्दों:
https://github.com/rust-lang/rust/issues/25477
https://github.com/rust-lang/rust/pull/34265

हो सकता है कि इसमें रसोई के सिंक को शामिल करने की आवश्यकता न हो, लेकिन इसमें एक रेंज पैरामीटर हो सकता है, ताकि यह नाली के सुपरसेट की तरह हो। उसमें कोई कमी? मुझे लगता है कि सीमा के लिए जाँच सीमा जोड़ना एक खामी है, यह एक और बात है जो घबरा सकती है। लेकिन drain_filter(.., f) नहीं कर सकता।

क्या कोई संभावना है कि यह निकट भविष्य में किसी न किसी रूप में स्थिर हो जाएगा?

यदि संकलक सीमा जाँच को समाप्त करने के लिए पर्याप्त चतुर है
drain_filter(.., f) मामले में मैं ऐसा करने का विकल्प चुनूंगा।

(और मुझे पूरा यकीन है कि आप इसे एक तरह से लागू कर सकते हैं
जो सबसे खराब में संकलक को चतुर बनाता है
यदि आपके पास "फ़ंक्शन विशेषज्ञता में" हो सकता है,
मूल रूप से if Type::of::<R>() == Type::of::<RangeFull>() { dont;do;type;checks; return } जैसा कुछ)

मुझे पता है कि यह कुछ हद तक बाइक शेडिंग है, लेकिन $#$ drain_where $#$ के बजाय इस drain_filter नामकरण करने के पीछे क्या तर्क था? मेरे लिए, पूर्व का तात्पर्य है कि पूरे Vec को निकाल दिया जाएगा, लेकिन यह कि हम परिणामों पर filter भी चलाते हैं (जब मैंने इसे पहली बार देखा, तो मैंने सोचा: "यह सिर्फ कैसे नहीं है .drain(..).filter() ?")। दूसरी ओर पूर्व इंगित करता है कि हम केवल उन तत्वों को हटाते हैं जहां कुछ शर्त होती है।

पता नहीं, लेकिन drain_where बहुत बेहतर लगता है और बहुत अधिक सहज ज्ञान युक्त है।
क्या अब भी इसे बदलने का मौका है?

.remove_if एक पूर्व सुझाव भी रहा है

मुझे लगता है कि drain_where इसे सबसे अच्छा समझाता है। ड्रेन की तरह यह मान लौटाता है, लेकिन यह सभी मानों को ड्रेन/हटा नहीं देता है, लेकिन ऐसे ही जहां दी गई शर्त सत्य है।

remove_if बहुत कुछ remove के एक सशर्त संस्करण की तरह लगता है जो एक शर्त सही होने पर इंडेक्स द्वारा केवल एक आइटम को हटा देता है उदाहरण के लिए letters.remove_if(3, |n| n < 10); इंडेक्स 3 पर अक्षर को हटा देता है यदि यह <10 है .

दूसरी ओर drain_filter थोड़ा अस्पष्ट है, क्या यह drain फिर filter अधिक अनुकूलित तरीके से (जैसे filter_map) करता है या यदि नाली करता है ताकि एक पुनरावर्तक को तुलनीय लौटाया जा सके पुनरावर्तक filter वापस आ जाएगा,
और यदि ऐसा नहीं है तो इसे filtered_drain नहीं कहा जाना चाहिए क्योंकि फ़िल्टर पहले तार्किक रूप से उपयोग किया जाता है ...

मानक पुस्तकालय में कहीं भी _where या _if का उपयोग करने के लिए कोई उदाहरण नहीं है।

@Gankro कहीं भी _filter का उपयोग करने के लिए कोई उदाहरण है? मैं यह भी नहीं जानता कि कम अस्पष्ट शब्दावली का उपयोग न करने का यही कारण है? मानक पुस्तकालय के अन्य स्थान पहले से ही विभिन्न प्रकार के प्रत्ययों का उपयोग करते हैं जैसे _until और _while ।

टिप्पणी में "कहा गया समकक्ष" कोड सही नहीं है ... आपको "यहाँ आपका कोड" साइट पर i से एक को घटाना होगा, या बुरी चीजें होती हैं।

आईएमओ यह filter नहीं है यह मुद्दा है। इसके लिए अभी खोज करने के बाद (और एक नौसिखिया होने के नाते), drain अन्य भाषाओं की तुलना में काफी गैर-मानक प्रतीत होता है।

फिर से, केवल एक नौसिखिया परिप्रेक्ष्य से, अगर मैं इस मुद्दे को प्रस्तावित करने के लिए कुछ खोजने की कोशिश कर रहा हूं तो मैं जो चीजें खोजूंगा वह delete (जैसा कि delete_if ), remove , filter या reject ।

मैंने वास्तव में filter के लिए _searched_ किया, drain_filter देखा और _बिना पढ़े खोज_ रखा क्योंकि drain उस साधारण चीज़ का प्रतिनिधित्व नहीं करता था जो मैं करना चाहता था।

ऐसा लगता है कि filter या reject नामक एक साधारण फ़ंक्शन अधिक सहज ज्ञान युक्त होगा।

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

        vec![
            "",
            "something",
            a_variable,
            function_call(),
            "etc",
        ]
            .reject(|i| { i.is_empty() })
            .join("/")

वर्तमान कार्यान्वयन के साथ, यह जिस पर शामिल होगा, वह अस्वीकृत मूल्य होगा।

मैं accept और reject दोनों को देखना चाहता हूं। इनमें से कोई भी मूल मान को परिवर्तित नहीं करता है।

आप पहले से ही filter साथ चेनिंग का काम कर सकते हैं। drain_filter का संपूर्ण बिंदु वेक्टर को बदलना है।

@rpjohnst तो मैंने यहां खोज की, क्या मुझे कहीं filter याद आ रही है?

हां, यह Iterator का सदस्य है, न कि Vec ।

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

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

rust consume vec के Google परिणाम के रूप में मुझे दस्तावेज़ों में drain_filter rust consume vec मिला। मुझे पता है कि जंग में डिफ़ॉल्ट रूप से अपरिवर्तनीयता के कारण, फ़िल्टर डेटा का उपभोग नहीं करता है, बस यह याद नहीं कर सकता कि इसे कैसे प्राप्त किया जाए ताकि मैं स्मृति को बेहतर तरीके से प्रबंधित कर सकूं।

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

मुझे अभी भी ऐसा लगता है जैसे drain_filter का अर्थ है कि यह नालियों (यानी, खाली) और फिर फ़िल्टर करता है। दूसरी ओर drain_where ऐसा लगता है जैसे यह उन तत्वों को हटा देता है जहां दी गई शर्त है (जो कि प्रस्तावित कार्य करता है)।

विधेय से मेल खाने वाले किसी भी शेष तत्व को हटाने के लिए linked_list::DrainFilter को Drop भी लागू नहीं करना चाहिए?

हां

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

मैं इस फ़ंक्शन का बहुत उपयोग कर रहा हूं और मुझे हमेशा उन प्रविष्टियों के लिए true वापस करना याद रखना होगा, जिन्हें मैं निकालना चाहता हूं, जो retain() / retain_mut() की तुलना में प्रति-सहज लगता है।
एक सहज तार्किक स्तर पर, उन प्रविष्टियों के लिए true वापस करना अधिक समझदारी होगी, जिन्हें मैं रखना चाहता हूं, क्या कोई और ऐसा महसूस करता है? (विशेष रूप से यह देखते हुए कि retain() पहले से ही इस तरह से काम करता है)
ऐसा क्यों न करें, और drain_filter() retain_iter() या retain_drain() (या drain_retain() ) कर दें?
तब यह retain() और अधिक बारीकी से प्रतिबिम्बित करेगा!

यही कारण है कि मैंने इसका नाम बदलने का प्रस्ताव रखा
drain_where के रूप में यह तब स्पष्ट है कि:

1. यह नाली का एक रूप है इसलिए हम नाम में नाली का उपयोग करते हैं

2. where के संयोजन में drain का उपयोग करके यह स्पष्ट है कि
   तत्व _कहां_ विधेय सत्य है, सूखा हो जाता है, अर्थात हटा दिया जाता है और लौटा दिया जाता है

3. यह एसटीडी में अन्य नामों के साथ तालमेल बिठाता है, आम तौर पर यदि आपके पास a
   दो विधेय से युक्त फ़ंक्शन का उपयोग करके आप इसका (मोटे तौर पर) अनुकरण कर सकते हैं
   प्रत्येक विधेय का प्रतिनिधित्व "और फिर" फैशन में करता है, उदाहरण के लिए
   filter_map का अनुकरण (लगभग) filter an then map के रूप में किया जा सकता है। द करेंट
   नाम इंगित करता है कि यह drain and then filter है, लेकिन यह इसके करीब भी नहीं है
   क्योंकि यह पूरी तरह से नाली नहीं करता है।

सूर्य पर, 25 फरवरी, 2018, 17:04 Boscop [email protected] ने लिखा:

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

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

लेकिन drain_where() के साथ क्लोजर को अभी भी हटाए जाने वाले तत्वों के लिए सही लौटना होगा, जो कि retain() के विपरीत है जो इसे असंगत बनाता है।
शायद retain_where ?
लेकिन मुझे लगता है कि आप सही हैं कि नाम में "नाली" होना समझ में आता है, इसलिए मुझे लगता है कि drain_retain() सबसे अधिक समझ में आता है: यह drain() जैसा है लेकिन उन तत्वों को बनाए रखना जहां क्लोजर रिटर्न true ।

हालांकि यह नहीं बदलता है, कि आपको सच लौटना होगा, यह स्पष्ट करता है कि
आपको ऐसा करना होगा।

मैं व्यक्तिगत रूप से या तो उपयोग करूंगा:

ए। drain_where
बी। retain_where
सी। retain

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

वर्तमान में retaim पहले से ही प्रमुख अंतर के साथ एसटीडी में लागू किया गया है
कि यह तत्वों को त्याग रहा है जबकि drain उन्हें वापस कर रहा है, जो बनाता है
retain (दुख की बात है) नाम में उपयोग के लिए अनुपयुक्त (सिवाय अगर आप कॉल करना चाहते हैं
यह retain_and_return या समान)।

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

सूर्य पर, 25 फरवरी, 2018, 18:01 Boscop [email protected] ने लिखा:

लेकिन ड्रेन_वेयर () के साथ क्लोजर को अभी भी सच लौटना होगा
ऐसे तत्व जिन्हें हटाया जाना चाहिए, जो कि बनाए रखने के विपरीत है () जो
असंगत बनाता है..
शायद बनाए रखें_कहां?
लेकिन मुझे लगता है कि आप सही कह रहे हैं कि नाम में "नाली" होना समझ में आता है,
तो मुझे लगता है कि drain_retain() सबसे अधिक समझ में आता है: यह नाली की तरह है () but
उन तत्वों को बनाए रखना जहां क्लोजर सही होता है।

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

लेकिन आप कितनी बार drain() से drain_filter() पर माइग्रेट करेंगे?
अब तक के सभी मामलों में, मैंने retain() से drain_filter() पर माइग्रेट किया क्योंकि एसटीडी में कोई retain_mut() नहीं है और मुझे तत्व को बदलने की आवश्यकता है! तो फिर मुझे क्लोजर रिटर्न वैल्यू को पलटना पड़ा।
मुझे लगता है कि drain_retain() समझ में आता है क्योंकि drain() विधि बिना शर्त सीमा के सभी तत्वों को हटा देती है, जबकि drain_retain() उन तत्वों को बरकरार रखती है जहां क्लोजर true लौटाता है, यह जोड़ती है drain() और retain() विधियों के प्रभाव।

क्षमा करें, मेरा मतलब drain_filter से drain_where पर माइग्रेट करना है।

कि आपके पास retain का उपयोग करके समाधान है और फिर उपयोग करने की आवश्यकता है
drain_filter एक पहलू है जिस पर मैंने अभी तक विचार नहीं किया है।

सूर्य पर, फरवरी 25, 2018, 19:12 Boscop [email protected] ने लिखा:

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

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

आह हाँ, लेकिन मुझे लगता है कि drain_filter() का उपयोग करने वाले मौजूदा कोड में क्लोजर को बदलने की "कीमत" इसके लायक है, एसटीडी में और फिर स्थिर में एक सुसंगत और सहज एपीआई प्राप्त करने के लिए।
यह केवल एक छोटी सी निश्चित लागत है (और इस तथ्य से आसान है कि यह फ़ंक्शन के नाम बदलने के साथ जाएगा, इसलिए संकलक त्रुटि उपयोगकर्ता को बता सकती है कि बंद करना उलटा होना चाहिए, इसलिए यह चुपचाप एक बग पेश नहीं करेगा) , drain_filter() को मानकीकृत करने की लागत की तुलना में और फिर retain() से drain_filter() में माइग्रेट करते समय लोगों को हमेशा बंद करना पड़ता है .. (याद रखने की मानसिक लागत के शीर्ष पर) ऐसा करें, और इसे दस्तावेज़ों में ढूंढना कठिन बनाने की लागत, retain() से आ रहा है और " retain() जैसा कुछ खोज रहा है लेकिन इसके बंद होने के लिए &mut पास कर रहा है, जो यही कारण है कि मुझे लगता है कि यह समझ में आता है कि इस फ़ंक्शन के नए नाम में नाम "बनाए रखना" है, ताकि दस्तावेज़ों में खोज करते समय लोग इसे ढूंढ सकें)।

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

मैं फिर से drain_retain क्यों हूं इसका कारण यह है कि जिस तरह से नाम वर्तमान में एसटीडी wrt में उपयोग किए जाते हैं। संग्रह:

1. आपके पास विधेय का उपयोग करते हुए फ़ंक्शन नाम हैं जिनके साथ उनके साथ जुड़े/उपभोग करने वाली अवधारणाएं हैं (wrt। जंग, पुनरावृत्तियों)। उदाहरण के लिए drain , collect , fold , all , take , ...
2. इस विधेय में कभी-कभी संशोधक होते हैं जैसे *_where , *_while
3. आपके पास विधेय का उपयोग करके फ़ंक्शन नाम हैं जिनमें संशोधित गुण हैं ( map , filter , skip , ...)
   
   
   
   • यहां यह अस्पष्ट है यदि यह तत्व या पुनरावृत्ति संशोधित है ( map बनाम filter / skip )
   
   
4. फ़ंक्शन नाम संशोधित गुणों का उपयोग करके कई विधेय का पीछा करते हैं जैसे filter_map
   
   
   
   • मोटे तौर पर apply modifier_1 and then apply modifier_2 की अवधारणा होने पर, बस एक चरण में ऐसा करना तेज़ या अधिक लचीला है
   
   

आपके पास कभी-कभी हो सकता है:

1. उत्पादन/उपभोग के संयोजन वाले फ़ंक्शन नाम संशोधित करने वाले के साथ विधेय (जैसे drain_filter )
   
   
   
   • _but_ अधिकांश बार उन्हें संशोधक के साथ संयोजित करना बेहतर/कम भ्रमित करने वाला होता है (जैसे drain_where )
   
   

आपके पास सामान्य रूप से नहीं है:

1. दो उत्पादक/उपभोक्ता विधेय एक नाम में संयुक्त हैं, अर्थात हमारे पास take_collect जैसा विचार नहीं है क्योंकि यह आसानी से भ्रमित करने वाला है

drain_retain थोड़े मायने रखता है लेकिन अंतिम श्रेणी में आता है, जबकि आप शायद अनुमान लगा सकते हैं कि यह मूल रूप से remove and return all elements "somehow specified" and then keep all elements "somehow specified" discarding other elements कहता है।

एक तरफ मुझे नहीं पता कि retain_mut क्यों नहीं होना चाहिए शायद एक त्वरित आरएफसी खोलना retain_mut को modify + retain को संयोजित करने के एक कुशल तरीके के रूप में पेश करना
स्थिर तो यह समारोह। तब तक आप प्रदान करने वाली एक विस्तार विशेषता लिखने पर विचार कर सकते हैं
आप retain_mut के मालिक हैं $# iter_mut + a bool-array (या bitarray, or...) का उपयोग करके किन तत्वों पर नज़र रखने के लिए
फिर से निकालना होगा। या अपना खुद drain_retain प्रदान करना जो आंतरिक रूप से drain_filer / drain_where का उपयोग करता है
लेकिन विधेय को |ele| !predicate(ele) नहीं में लपेटता है।

@dathinab

1. हम यहां संग्रह पर एक विधि के बारे में बात कर रहे हैं, इटरेटर पर नहीं। नक्शा, फ़िल्टर, फ़िल्टर_मैप, छोड़ें, टेक_जबकि इत्यादि इटरेटर पर सभी विधियां हैं। बीटीडब्ल्यू, आपका क्या मतलब है कि *_where का उपयोग करें?
   इसलिए हमें नामकरण योजना की तुलना उन तरीकों से करनी होगी जो पहले से ही संग्रह पर मौजूद हैं, जैसे retain() , drain() । इटरेटर विधियों के साथ कोई भ्रम नहीं है जो एक इटरेटर को दूसरे इटरेटर में बदल देता है।
2. AFAIK आम सहमति थी कि retain_mut() को एसटीडी में नहीं जोड़ा जाएगा क्योंकि drain_filter() पहले से ही जोड़ा जाएगा और लोगों को इसका उपयोग करने की सलाह दी गई थी। जो हमें retain() से drain_filter() में माइग्रेट करने के उपयोग के मामले में वापस लाता है, इसलिए इसका एक समान नाम और एपीआई होना चाहिए (क्लोजर रिटर्निंग true का अर्थ है प्रविष्टि रखना )..

मुझे इस बात की जानकारी नहीं है कि retain_mut पर पहले ही चर्चा हो चुकी है।

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

• _where प्रत्यय के लिए थोड़ा संशोधित व्यक्त करने के लिए सिर्फ एक उदाहरण है
  समारोह। इस प्रकार के प्रत्यय जो वर्तमान में एसटीडी में प्रयुक्त होते हैं, वे मुख्य रूप से हैं
  _until , _while , _then , _else , _mut और _back ।

drain_retain भ्रमित करने का कारण यह है कि यह स्पष्ट नहीं है कि क्या यह है
ड्रेन या रिटेन बेस्ड, अगर यह ड्रेन बेस्ड है, तो रिटर्न ट्रू हटा देगा
मूल्य, अगर बनाए रखा है तो यह इसे रखेगा। _where का उपयोग करना इसे यहां बनाता है
अंतिम स्पष्ट करें कि पारित समारोह से क्या अपेक्षित है।

सोम, 26 फरवरी, 2018 को 00:25 Boscop [email protected] ने लिखा:

@dathinab https://github.com/dathinab

1. हम यहां संग्रह पर एक विधि के बारे में बात कर रहे हैं, इटरेटर पर नहीं।
   नक्शा, फ़िल्टर, फ़िल्टर_मैप, छोड़ें, टेक_जबकि इत्यादि इटरेटर पर सभी विधियां हैं।
   बीटीडब्ल्यू, आपका क्या मतलब है कि *_कहां का उपयोग करें?
   इसलिए हमें नामकरण योजना की तुलना उन विधियों से करनी होगी जो पहले से मौजूद हैं
   संग्रह पर, उदाहरण के लिए बनाए रखें (), नाली ()। इसमें कोई भ्रम नहीं है
   इटरेटर विधियां जो इटरेटर को दूसरे इटरेटर में बदल देती हैं।
2. AFAIK आम सहमति थी कि रिटेन_म्यूट () को एसटीडी में नहीं जोड़ा जाएगा
   क्योंकि ड्रेन_फिल्टर () पहले ही जोड़ दिया जाएगा और लोगों को सलाह दी गई थी
   इसका उपयोग करने के लिए। जो हमें माइग्रेट करने के उपयोग के मामले में वापस लाता है
   रिटेन () से ड्रेन_फिल्टर () बहुत सामान्य है, इसलिए इसमें a . होना चाहिए
   समान नाम और एपीआई (सच लौटने का मतलब है प्रविष्टि रखना) ..

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।

इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/rust-lang/rust/issues/43244#issuecomment-368355110 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AHR0kfkRAZ5OtLFZ-SciAmjHDEXdgp-0ks5tYevegaJpZM4OY1me
.

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

एफडब्ल्यूआईडब्ल्यू, मुझे लगता है कि retain यहां काउंटर-सहज ज्ञान युक्त नाम है। मैं आमतौर पर खुद को वेक्टर से कुछ तत्वों को हटाना चाहता हूं, और retain के साथ मुझे हमेशा उस तर्क को उलटना पड़ता है।

लेकिन retain() पहले से ही स्थिर है, इसलिए हमें इसके साथ रहना होगा.. और इसलिए मेरे अंतर्ज्ञान को इसकी आदत हो गई है..

@ बॉस्कोप : और ऐसा ही drain है जो retain का विलोम है, लेकिन हटाए गए तत्वों और प्रत्ययों के उपयोग को भी लौटाता है _until , _while बनाने के लिए उपलब्ध फ़ंक्शंस जो मौजूदा कार्यक्षमता का थोड़ा संशोधित संस्करण हैं।

मेरा मतलब है कि अगर मैं नाली का वर्णन करता हूं तो यह कुछ ऐसा होगा:

_ "किसी तरह" निर्दिष्ट सभी तत्वों को हटाएं और वापस करें, अन्य सभी तत्वों को रखें_
जहां _"किसी तरह"_ _"काटने से"_ सभी स्लाइस करने योग्य संग्रह प्रकारों के लिए और बाकी के लिए _"सभी"_ है।

यहां चर्चा किए गए फ़ंक्शन का विवरण _वही_ है सिवाय इसके कि
_"किसी तरह"_ is _" जहां दिया गया विधेय सत्य लौटाता है"_।

एक तरफ जो विवरण मैं बरकरार रखूंगा वह है:
_केवल उन तत्वों को बनाए रखें (अर्थात रखें) जहां एक दिया गया विधेय सत्य लौटाता है, बाकी को छोड़ दें_

(हां, रिटेन का इस्तेमाल इस तरह से किया जा सकता था जहां यह बाकी को नहीं छोड़ता, दुख की बात है कि ऐसा नहीं था)

मुझे लगता है कि यह वास्तव में अच्छा होता अगर retain होता
विधेय में &mut T पारित किया और शायद हटाए गए मान वापस कर दिए।
क्योंकि मुझे लगता है कि retain एक अधिक सहज नाम आधार है।

लेकिन इससे स्वतंत्र मुझे यह भी लगता है कि दोनों drain_filter / drain_retain उप-इष्टतम हैं
क्योंकि वे यह स्पष्ट नहीं करते हैं कि विधेय को एक प्रविष्टि रखने/निकालने के लिए सही/गलत वापस करना है या नहीं।
(नाली इंगित करती है कि सत्य इसे हटा देता है क्योंकि यह फ़िल्टर करते समय तत्वों को हटाने के बारे में बोलता है
और पीछे हटना बोलता है कि किन तत्वों को रखना है, अंत में जंग में)

अंत में यह महत्वपूर्ण नहीं है कि किस नाम का प्रयोग किया जाता है, यह स्थिर हो जाए तो अच्छा होगा।

मतदान करना और/या भाषा टीम के किसी व्यक्ति को निर्णय लेने देना, सोच को आगे बढ़ाने का सबसे अच्छा तरीका हो सकता है?

मुझे लगता है कि drain_where , drain_if , या drain_when जैसा कुछ drain_filter से कहीं अधिक स्पष्ट है।

@tmccombs उन 3 में से, मुझे लगता है कि drain_where सबसे अधिक समझ में आता है। (क्योंकि if का अर्थ है either do the whole thing (in this case draining) or not और when अस्थायी है।)
drain_filter की तुलना में क्लोजर रिटर्न वैल्यू drain_where ( किसी तत्व को हटाने के लिए true ) के साथ समान है, लेकिन उस तथ्य को नाम से स्पष्ट / स्पष्ट किया गया है, इसलिए यह समाप्त कर देता है क्लोजर रिटर्न वैल्यू के गलत अर्थ की गलती से व्याख्या करने का जोखिम।

मुझे लगता है कि यह स्थिर होने के लिए समय से अधिक है। इस सूत्र का सारांश:

• क्या R: RangeArgument पैरामीटर जोड़ा जाना चाहिए?
• क्या बूलियन मान उलटा होना चाहिए? (मुझे लगता है कि वर्तमान तर्क समझ में आता है: कॉलबैक से true लौटने से उस आइटम को इटरेटर में शामिल किया जा सकता है।)
• नामकरण। (मुझे drain_where पसंद है।)

@ गैंक्रो , आपको क्या लगता है?

libs टीम ने इस पर चर्चा की और सर्वसम्मति इस समय अधिक drain जैसी विधियों को स्थिर नहीं करने के लिए थी। (मौजूदा drain_filter विधि नाइटली में अस्थिर के रूप में रह सकती है।) https://github.com/rust-lang/rfcs/pull/2369 एक और नाली जैसा पुनरावर्तक जोड़ने का प्रस्ताव करता है जो गिराए जाने पर कुछ नहीं करता है (इटरेटर को इसके अंत तक उपभोग करने के विपरीत)।

हम एक छोटे एपीआई सतह में जल निकासी के विभिन्न संयोजनों को सामान्यीकृत करने का प्रयास करने के लिए प्रयोग देखना चाहते हैं:

• एक उप-श्रेणी ( RangeArgument उर्फ RangeBounds के माध्यम से) बनाम संपूर्ण संग्रह (हालांकि बाद वाले को .. पास करके प्राप्त किया जा सकता है, RangeFull प्रकार का मान )
• सब कुछ निकालना (संभवतः उस सीमा के भीतर) बनाम केवल तत्व जो एक बूलियन भविष्यवाणी से मेल खाते हैं
• ड्रॉप बनाम नॉट पर सेल्फ-थकाऊ (संग्रह में बाकी तत्वों को छोड़कर)।

संभावनाओं में इसे सामान्य, या एक बिल्डर पैटर्न बनाकर एक विधि "ओवरलोडिंग" शामिल हो सकती है।

एक बाधा यह है कि drain विधि स्थिर है। इसे संभवतः सामान्यीकृत किया जा सकता है, लेकिन केवल पिछड़े-संगत तरीकों से।

हम एक छोटे एपीआई सतह में जल निकासी के विभिन्न संयोजनों को सामान्यीकृत करने का प्रयास करने के लिए प्रयोग देखना चाहते हैं:

टीम इस प्रकार के प्रयोग को कैसे और कहाँ देखती है?

कैसे: एक ठोस एपीआई डिजाइन के साथ आओ और प्रस्तावित करें, संभवतः एक प्रूफ-ऑफ-कॉन्सेप्ट कार्यान्वयन के साथ (जिसे कम से कम Vec::as_mut_ptr और Vec::set_len के माध्यम से पेड़ से बाहर किया जा सकता है)। जहां ज्यादा मायने नहीं रखता। https://internals.rust-lang.org/c/libs में एक नया RFC या थ्रेड हो सकता है, और इसे यहां से लिंक करें।

मैं इसके साथ थोड़ी देर के लिए खेल रहा हूं। मैं अगले दिनों में इंटर्नल पर एक सूत्र खोलूंगा।

मुझे लगता है कि इस तरह काम करने वाला एक सामान्य एपीआई समझ में आता है:

    v.drain(a..b).where(pred)

तो यह एक बिल्डर-स्टाइल एपीआई है: यदि .where(pred) को जोड़ा नहीं गया है, तो यह बिना शर्त पूरी रेंज को खत्म कर देगा।
इसमें वर्तमान .drain(a..b) पद्धति के साथ-साथ .drain_filter(pred) की क्षमताएं शामिल हैं।

यदि नाम drain का उपयोग नहीं किया जा सकता है क्योंकि यह पहले से उपयोग में है, तो यह समान नाम होना चाहिए जैसे drain_iter ।

परिणामी पुनरावर्तक को फ़िल्टर करने के साथ भ्रम से बचने के लिए where विधि का नाम *_filter नहीं होना चाहिए, खासकर जब where और filter इस तरह संयोजन में उपयोग किए जाते हैं:

    v.drain(..).where(pred1).filter(pred2)

यहां, यह तय करने के लिए pred1 का उपयोग करेगा कि क्या निकाला जाएगा (और इटरेटर में पारित किया जाएगा) और परिणामी इटरेटर को फ़िल्टर करने के लिए pred2 का उपयोग किया जाता है।
कोई भी तत्व जो pred1 के लिए true $ लौटाता है, लेकिन pred2 के लिए false #$ लौटाता है, वह अभी भी v से निकल जाएगा, लेकिन इसके द्वारा प्राप्त नहीं होगा यह संयुक्त पुनरावर्तक।

आप इस प्रकार के निर्माता-शैली API दृष्टिकोण के बारे में क्या सोचते हैं?

एक सेकंड के लिए मैं भूल गया कि where को फ़ंक्शन नाम के रूप में उपयोग नहीं किया जा सकता क्योंकि यह पहले से ही एक कीवर्ड है: /

और drain पहले से ही स्थिर है इसलिए नाम का उपयोग भी नहीं किया जा सकता है..

तब मुझे लगता है कि दूसरा सबसे अच्छा समग्र विकल्प मौजूदा drain रखना और drain_filter से drain_where का नाम बदलना है, ताकि भ्रम से बचने के लिए .drain(..).filter() ।

(जैसा कि जोंहू ने ऊपर कहा:)

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

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

संपादित करें: मैंने अपना प्रयोगात्मक कोड अपलोड कर दिया है: ड्रेन प्रयोग
नाली और समाशोधन बेंच और कुछ परीक्षण भी हैं लेकिन स्वच्छ कोड की अपेक्षा नहीं करते हैं।

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

@Emerentius लेकिन फिर हमें कम से कम drain_filter से drain_where का नाम बदलना चाहिए, यह इंगित करने के लिए कि तत्व को हटाने के लिए क्लोजर को true वापस करना होगा!

@ बॉस्कोप दोनों true => उपज की समान 'ध्रुवीयता' का संकेत देते हैं। मुझे व्यक्तिगत रूप से परवाह नहीं है कि इसे drain_filter या drain_where कहा जाता है।

@ पोपोग क्या आप मतभेदों और पेशेवरों और विपक्षों को संक्षेप में बता सकते हैं? आदर्श रूप से आंतरिक धागे पर। मुझे लगता है कि DoubleEndedIterator कार्यक्षमता को शून्य या निम्न ओवरहेड के साथ संगत रूप से जोड़ा जा सकता है (लेकिन मैंने इसका परीक्षण नहीं किया है)।

कैसे के बारे में drain_or_retain ? यह एक व्याकरणिक रूप से सार्थक क्रिया है, और यह संकेत देती है कि यह एक या दूसरे को करती है।

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

नाली को सीमित/रोकने/रद्द करने/निरस्त करने का कोई तरीका हो तो अच्छा होगा। उदाहरण के लिए, यदि मैं पहले N सम संख्याओं को निकालना चाहता हूं, तो यह अच्छा होगा कि मैं केवल vec.drain_filter(|x| *x % 2 == 0).take(N).collect() (या उस के कुछ प्रकार) को करने में सक्षम हो।

जैसा कि यह वर्तमान में लागू किया गया है, DrainFilter की drop विधि हमेशा नाली को पूरा करने के लिए चलाएगी; इसे निरस्त नहीं किया जा सकता है (कम से कम मैंने ऐसा कोई तरकीब नहीं निकाला है जो ऐसा करेगी)।

यदि आप उस व्यवहार को चाहते हैं तो आपको किसी ऐसे राज्य को बंद कर देना चाहिए जो ट्रैक करता है कि आपने कितने देखे हैं और झूठी वापसी शुरू कर दी है। एडेप्टर को यथोचित व्यवहार करने के लिए ड्रॉप पर पूरा करने के लिए दौड़ना आवश्यक है।

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

मुझे पता है कि Vec डिफ़ॉल्ट रूप से सुरक्षित नहीं है, लेकिन drain_filer का व्यवहार है जब
विधेय आतंक अच्छी तरह से आश्चर्यजनक है क्योंकि:

1. यह बंद होने पर कॉल करना जारी रखेगा जो ड्रॉप होने पर घबरा गया था
   अगर बंद होने से फिर से घबराहट होती है तो यह एक सवार का कारण बनेगा और जबकि कुछ लोग
   त्रुटि-कर्नेल पैटर्न के साथ और उनके लिए अन्य कामों पर सवार होने के लिए सभी आतंक की तरह
   एक सवार के साथ समाप्त होना काफी बुरा है
2. यदि सही ढंग से जल निकासी जारी नहीं रहेगी तो संभावित रूप से एक मान
   और जिसमें एक मान पहले से ही संभावित रूप से गिरा दिया गया हो, जिसके कारण फ्री के बाद उपयोग किया जा सकता है

इस व्यवहार का एक उदाहरण यहाँ है:
play.rust-lang.org

जबकि 2. बिंदु हल करने योग्य होना चाहिए, मुझे लगता है कि पहला बिंदु स्वयं ही होना चाहिए
पूरा करने के लिए चलाने के लिए DrainFilter के व्यवहार पर पुनर्विचार करने के लिए नेतृत्व करें
ड्रॉप पर, इसे बदलने के कारणों में शामिल हैं:

• इटरेटर जंग में आलसी होते हैं, ड्रॉप करते समय एक इटरेटर को निष्पादित करना थोड़े अप्रत्याशित व्यवहार होता है
  जो सामान्य रूप से अपेक्षित होता है, उससे व्युत्पन्न
• drain_filter को पारित विधेय कुछ परिस्थितियों में घबरा सकता है (उदाहरण के लिए एक ताला
  जहर हो गया) जिस स्थिति में ड्रॉप लीडिंग के दौरान कॉल करने पर फिर से घबराने की संभावना है
  एक दोहरे आतंक के लिए और इसलिए सवार, जो त्रुटि कर्नेल का उपयोग करने वाले किसी के लिए भी काफी बुरा है
  पैटर्न या अंत में नियंत्रित तरीके से बंद करना चाहते हैं, तो यह ठीक है यदि आप किसी भी तरह से आतंक = सवार का उपयोग करते हैं
• यदि आपके पास विधेय में दुष्प्रभाव हैं और पूरा होने के लिए DrainFilter नहीं चलाते हैं तो आपको मिल सकता है
  आश्चर्यजनक बग जब इसे गिराए जाने पर पूरा करने के लिए चलाया जाता है (लेकिन आपने किया हो सकता है
  दूसरा इसे एक बिंदु पर निकालने और इसे गिराने के बीच सोचता है)
• आप इसे दिए गए विधेय को संशोधित किए बिना इस व्यवहार से ऑप्ट-आउट नहीं कर सकते हैं, जिसे आप
  हो सकता है कि आप इसे लपेटे बिना नहीं कर सकें, दूसरी ओर आप हमेशा चलने के लिए ऑप्ट-इन कर सकते हैं
  इसे पूरा करने के लिए केवल इटरेटर को पूरा करने के लिए (हाँ यह अंतिम तर्क थोड़ा सा है)
  हाथ में लहरदार)

पूरा करने के लिए चलने के तर्कों में शामिल हैं:

• drain_filter ratain $ के समान है जो एक फ़ंक्शन है, इसलिए लोग आश्चर्यचकित हो सकते हैं जब वे
  "बस" इसे पूरा करने के लिए चलाने के बजाय DrainFilter ड्रॉप करें
  
  
  
  • इस तर्क का अन्य RFC में कई बार विरोध किया गया और यही कारण है कि #[unused_must_use]
    
    मौजूद है, जो कुछ स्थितियों में पहले से ही .for_each(drop) का उपयोग करने की अनुशंसा करता है जो विडंबना है
    
    वही होता है जो DrainFilter ड्रॉप पर करता है
  
  
• drain_filter का उपयोग अक्सर केवल इसके साइड इफेक्ट के लिए किया जाता है, इसलिए यह क्रिया के लिए है
  
  
  
  • इसका इस तरह से उपयोग करने से यह लगभग retain . के बराबर हो जाता है
    
    
    
    
    
    • लेकिन &T का उपयोग बनाए रखें, ड्रेन_फिल्टर का उपयोग किया गया &mut T
    
    
    
  
  
• अन्य??
• [संपादित करें, बाद में जोड़ा गया, THX @tmccombs ]: find , all , any जैसे एडेप्टर के साथ संयुक्त होने पर ड्रॉप पर पूरा नहीं करना बहुत भ्रमित हो सकता है, जो कि मैं काफी अच्छा कारण हूं वर्तमान व्यवहार रखने के लिए।

यह सिर्फ मैं हो सकता है या मैं कुछ बिंदु चूक गया लेकिन Drop व्यवहार को बदल रहा हूं और
#[unused_must_use] जोड़ना बेहतर लगता है?

अगर .for_each(drop) लंबा है तो हम इसके बजाय इटरेटर के लिए एक आरएफसी जोड़ने पर विचार कर सकते हैं
इटरेटर (या अच्छी तरह से drain() लेकिन यह complete() जैसी विधि जोड़ने का दुष्प्रभाव है
पूरी तरह से अलग चर्चा है)

अन्य??

मुझे मूल तर्क नहीं मिल रहा है, लेकिन मुझे याद है कि DrainFilter के साथ काम करने वाले एडेप्टर के साथ भी कुछ समस्या थी जो पूरा नहीं होता है।

यह भी देखें https://github.com/rust-lang/rust/issues/43244#issuecomment -394405057

अच्छी बात है, उदाहरण के लिए find के कारण नाला तब तक बहेगा जब तक कि यह पहली बार हिट न हो जाए
मैच, समान all , any शॉर्ट सर्किट करते हैं, जो काफी भ्रमित करने वाला हो सकता है
रिट नाली।

हम्म, शायद मुझे अपनी राय बदलनी चाहिए। इसके माध्यम से एक सामान्य समस्या हो सकती है
साइड-इफेक्ट वाले पुनरावृत्तियों के साथ और शायद हमें एक सामान्य समाधान पर विचार करना चाहिए
(इस ट्रैकिंग समस्या से स्वतंत्र) एक .allways_complete() एडेप्टर की तरह।

मुझे व्यक्तिगत रूप से कोई सुरक्षा कारण नहीं मिला है कि नाली को पूरा करने की आवश्यकता क्यों है, लेकिन जैसा कि मैंने यहां ऊपर कुछ पोस्ट लिखे हैं, next() पर साइड-इफेक्ट एडेप्टर के साथ एक उप-रूप में इंटरैक्ट करते हैं जैसे कि take_while , peekable और skip_while ।

यह गैर-सेल्फ-थकाऊ ड्रेन पर मेरे RFC और इसके साथी सेल्फ- एक्सहॉस्टिंग इटर एडेप्टर RFC के समान मुद्दों को भी सामने लाता है।

यह सच है कि drain_filter आसानी से गर्भपात का कारण बन सकता है लेकिन क्या आप इसका उदाहरण दिखा सकते हैं कि यह सुरक्षा का उल्लंघन कहां करता है?

हाँ, मैंने पहले ही कर लिया: play.rust-lang.org

यह कौन सा है:

#![feature(drain_filter)]

use std::panic::catch_unwind;

struct PrintOnDrop {
    id: u8
}

impl Drop for PrintOnDrop {
    fn drop(&mut self) {
        println!("dropped: {}", self.id)
    }
}

fn main() {
    println!("-- start --");
    let _ = catch_unwind(move || {
        let mut a: Vec<_> = [0, 1, 4, 5, 6].iter()
            .map(|&id| PrintOnDrop { id })
            .collect::<Vec<_>>();

        let drain = a.drain_filter(|dc| {
            if dc.id == 4 { panic!("let's say a unwrap went wrong"); }
            dc.id < 4
        });

        drain.for_each(::std::mem::drop);
    });
    println!("-- end --");
    //output:
    // -- start --
    // dropped: 0    <-\
    // dropped: 1       \_ this is a double drop
    // dropped: 0  _  <-/
    // dropped: 5   \------ here 4 got leaked (kind fine)  
    // dropped: 6
    // -- end --

}

लेकिन यह एक कार्यान्वयन आंतरिक सोच है, जो गलत हो गया।
मूल रूप से खुला प्रश्न यह है कि एक विधेय समारोह के panic को कैसे संभालना है:

1. उस तत्व को छोड़ दें जिससे वह घबरा गया था, उसे लीक कर दिया और डेल काउंटर बढ़ा दिया
   
   
   
   • पैनिक डिटेक्शन के किसी न किसी रूप की आवश्यकता होती है
   
   
2. विधेय को कॉल करने से पहले idx को आगे न बढ़ाएं
   
   
   
   • लेकिन इसका मतलब है कि ड्रॉप पर इसे फिर से उसी विधेय के साथ बुलाया जाएगा
   
   

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

शायद एक विचार कुछ ऐसा हो सकता है:

1. next दर्ज करते समय ध्वज सेट करें, next . से लौटने से पहले इसे अनसेट करें
2. ड्रॉप पर अगर झंडा अभी भी सेट है तो हम जानते हैं कि हम घबरा गए हैं और इसलिए लीक हो गए हैं
   शेष आइटम या शेष सभी आइटम छोड़ दें
   
   
   
   1. अप्रत्याशित साइड इफेक्ट के साथ काफी बड़ा रिसाव हो सकता है यदि आप उदाहरण के लिए एक आर्क लीक करते हैं
   
   
   2. यदि आपके पास आर्क और वीक है तो बहुत आश्चर्य हो सकता है
   
   

शायद कोई बेहतर उपाय हो।
जो भी हो, उसे एक बार लागू करने के बाद रस्टडॉक में प्रलेखित किया जाना चाहिए।

@dathinab

हाँ, मैंने पहले ही किया था

रिसाव अवांछनीय है लेकिन ठीक है और यहां से बचना मुश्किल हो सकता है, लेकिन डबल-ड्रॉप निश्चित रूप से नहीं है। अच्छी कैच! क्या आप इस सुरक्षा समस्या के बारे में एक अलग समस्या की रिपोर्ट करना चाहेंगे?

क्या drain_filter हर बार संग्रह से किसी आइटम को निकालने पर पुन: आवंटन करता है? या यह केवल एक बार पुन: आवंटित करता है और सी ++ में std::remove और std::erase (जोड़ी में) की तरह काम करता है? मैं ठीक एक आवंटन के कारण ऐसा व्यवहार पसंद करूंगा: हम बस अपने तत्वों को संग्रह के अंत में रखते हैं और फिर इसे उचित आकार में सिकोड़ते हैं।

साथ ही, try_drain_filter क्यों नहीं है? अगर हमें रुकना चाहिए तो कौन सा Option प्रकार, और None मान देता है? मेरे पास बहुत बड़ा संग्रह है और मेरे लिए इसे जारी रखना व्यर्थ है जब मुझे पहले से ही वह मिल गया जिसकी मुझे आवश्यकता थी।

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

शुक्र, अगस्त 10, 2018, 07:11 पर Victor Polevoy [email protected] ने लिखा:

क्या हर बार जब यह किसी आइटम को हटाता है तो ड्रेन_फिल्टर रीयललोकेशन करता है
संग्रह? या यह केवल एक बार पुन: आवंटन करता है और std::remove . की तरह काम करता है
और सी++ में std::erase (जोड़ी में)? मैं इस तरह के व्यवहार को पसंद करूंगा क्योंकि
बिल्कुल एक आवंटन: हम बस अपने तत्वों को संग्रह के अंत में रखते हैं
और फिर इसे हटाकर उचित आकार में सिकोड़ें।

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

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

@rustonaut धन्यवाद। try_drain_filter के बारे में आपकी क्या राय है? :)

पीएस बस कोड को भी देखा, ऐसा लगता है कि यह वैसे ही काम करता है जैसे हम चाहते थे।

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

तो यह संभावना नहीं है कि आपको एक कोशिश संस्करण मिलेगा जो आपके जैसा व्यवहार करता है
अपेक्षा करना।

निष्पक्षता नाली के लिए जल्दी रोकना जब वास्तव में पुनरावृत्त करना भ्रमित हो सकता है
कुछ स्थितियां जैसे thing.drain_where(|x| x.is_malformed()).any(|x| x.is_dangerus()) सभी विकृतियों को खत्म नहीं करेंगी, लेकिन केवल एक . तक
मिला है जो खतरनाक भी है। (मौजूदा इम्प्ल। सभी विकृतियों को हटा देता है
बूंद पर जल निकासी जारी रखते हुए)।

शुक्र, अगस्त 10, 2018 को, 10:52 विक्टर पोलवॉय नोटिफिकेशन @github.com ने लिखा:

@rustonaut https://github.com/rustonaut धन्यवाद। आपकी क्या राय है
try_drain_filter के बारे में? :)

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

मुझे लगता है कि यह अधिक बहुमुखी होगा:

fn drain_filter_map<F>(&mut self, f: F) -> DrainFilterMap<T, F> where F: FnMut(T) -> Option<T>

नमस्ते, मैं drain_filter कार्यक्षमता के लिए HashMap की खोज कर रहा था, लेकिन यह मौजूद नहीं है, और जब मुझे यह मिला तो मुझे एक मुद्दा खोलने के लिए कहा गया। क्या यह एक अलग मुद्दे में होना चाहिए?

क्या वर्तमान में कोई चीज़ इसे स्थिरीकरण से रोक रही है? जैसा कि ऊपर बताया गया है, क्या यह अभी भी खोलना-असुरक्षित है?

यह एक बहुत छोटी विशेषता की तरह लगता है, और यह एक साल से अधिक समय से अधर में है।

मुझे लगता है कि यह अधिक बहुमुखी होगा:

fn drain_filter_map<F>(&mut self, f: F) -> DrainFilterMap<T, F> where F: FnMut(T) -> Option<T>

मुझे नहीं लगता कि यह drain_filter और map की रचना से बेहतर है।

जैसा कि ऊपर बताया गया है, क्या यह अभी भी खोलना-असुरक्षित है?

यदि पुनरावृत्ति जल्दी बंद हो जाती है, तो सभी मिलान तत्वों को न निकालने के बीच एक कठिन विकल्प प्रतीत होता है, या DrainFilter की गिरावट पर फ़िल्टरिंग और अंत तक निकालने पर संभावित घबराहट के दौरान संभावित घबराहट होती है।
मुझे लगता है कि यह सुविधा किसी भी तरह से समस्याओं से भरी हुई है और इसलिए इसे स्थिर नहीं किया जाना चाहिए।

क्या इसे खोलने पर अलग तरीके से व्यवहार करने में कोई विशेष समस्या है?

संभावनाएं:

• यह सामान्य रूप से पूरा होने तक चल सकता है, लेकिन मेल खाने वाले तत्वों को पीछे छोड़ दें (ताकि सभी शेष तत्वों का मिलान न हो)।
• यह सामान्य रूप से पूरा होने के लिए चल सकता है, लेकिन अंतिम लिखित स्थिति के बाद वेक्टर को छोटा कर दें (ताकि सभी शेष तत्वों का मिलान हो)।
• यह सामान्य रूप से पूरा होने तक चल सकता है, लेकिन वेक्टर को खोलने पर लंबाई 0 तक छोटा कर सकता है।

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

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

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

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

जहां तक ​​मैं जानता हूं कि आप डबल पैनिक _is sound_ के रूप में मार्क या अनसाउंड नहीं कर सकते हैं
बस बहुत असुविधाजनक है क्योंकि यह निरस्त हो जाता है। साथ ही जहाँ तक मुझे याद है
डबल पैनिकिंग की संभावना कोई बग नहीं है बल्कि व्यवहार परोक्ष रूप से है
जानबूझकर चुना गया।

विकल्प मूल रूप से हैं:

1. ड्रॉप पर पूरा करने के लिए दौड़ें नहीं।
2. पूर्ण होने के लिए दौड़ें लेकिन संभावित रूप से दोहरे आतंक के कारण निरस्त करें
3. घबराहट के दौरान सभी "अनियंत्रित" तत्वों को ड्रॉप पर छोड़ दें।
4. घबराहट के दौरान ड्रॉप पर पूरा न करें।

समस्याएं हैं:

1. => कई उपयोग के मामलों में अप्रत्याशित व्यवहार।
2. => अनपेक्षित गर्भपात यदि विधेय घबरा सकता है, खासकर यदि आप इसका उपयोग करते हैं
   तत्वों को "बस" हटाने के लिए, यानी आप लौटाए गए इटरेटर का उपयोग नहीं करते हैं।
3. => घबराहट के अंदर और बाहर के बीच अप्रत्याशित अंतर। अभी - अभी
   ड्रॉप फंक्शन में किसी को _उपयोग_ड्रेन_फिल्टर पर विचार करें।
4. => 3 देखें।

या दूसरे शब्दों में 1. सामान्य उपयोग के मामलों में भ्रम पैदा करता है, 2. नेतृत्व कर सकता है
गर्भपात करने के लिए अगर विधेय घबरा सकता है 3.,4। इसे बनाएं ताकि आप वास्तव में नहीं कर सकें
इसे एक ड्रॉप विधि में उपयोग करें, लेकिन अब आप वहां एक फ़ंक्शन का उपयोग कैसे करते हैं?
आंतरिक रूप से इसका उपयोग नहीं करता है।

इस विकल्प के परिणामस्वरूप 3.,4. नो-गो हैं। विकल्प 2 के साथ समस्याएं हैं
अधिक दुर्लभ तो 1 में वाले। इसलिए 2 को चुना गया था।

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

सोम, 20 मई, 2019, 09:28 को राल्फ जंग नोटिफिकेशन @github.com ने लिखा:

साउंडनेस बग के लिए एक अलग मुद्दा खोलने लायक हो सकता है? वह हो सकता है
फिर I-unsound के रूप में चिह्नित किया जाए।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/rust-lang/rust/issues/43244?email_source=notifications&email_token=AB2HJEL7FS6AA2A2KF5U2S3PWJHK7A5CNFSM4DTDLGPKYY3PNVWWK3TUL52HS4DFVREXG43VMV93RWZ63GOD92 मुद्दा
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AB2HJEMHQFRTCH6RCQQ64DTPWJHK7ANCNFSM4DTDLGPA
.

डबल- ड्रॉप हालांकि अस्वस्थ हैं।

बेहतरी की समस्या के लिए #60977 बनाया गया

धन्यवाद, मैं डबल ड्रॉप को डबल पैनिक के रूप में पढ़ने के लिए बेवकूफ महसूस करता हूं: man_facepalming:।

1. => घबराहट के अंदर और बाहर के बीच अप्रत्याशित अंतर। अभी - अभी
   ड्रॉप फंक्शन में किसी को _उपयोग_ड्रेन_फिल्टर पर विचार करें।

3.,4. इसे बनाएं ताकि आप वास्तव में नहीं कर सकें
इसे एक ड्रॉप विधि में उपयोग करें, लेकिन अब आप वहां एक फ़ंक्शन का उपयोग कैसे करते हैं?
आंतरिक रूप से इसका उपयोग नहीं करता है।

मेरे लिए यह अभी भी कोई बड़ी बात नहीं है।

अगर कोई ड्रॉप इंप में drain_filter का उपयोग ऐसी स्थिति के साथ करता है जो घबरा सकती है, तो समस्या यह नहीं है कि उन्होंने drain_filter का उपयोग करना चुना; इसी तरह इससे कोई फर्क नहीं पड़ता कि कोई विधि आंतरिक रूप से drain_filter का उपयोग करती है या नहीं;

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

ठीक है, तो आपका तर्क यह है कि drop impl के अंदर का कोड जो $#$ drain_filter का उपयोग करता है, रहस्यमय तरीके से टूट सकता है यदि यह आराम के दौरान चलाने के लिए होता है। (यह drain_filter घबराहट के बारे में नहीं है, लेकिन अन्य कोड पैनिकिंग के बारे में है जो drain_filter को चलाने का कारण बनता है):

impl Drop for Type {
    fn drop(&mut self) {
        self.vec.drain_filter(|x| x == 3);

        // Do stuff that assumes the vector has no 3's
        ...
    }
}

यह ड्रॉप इम्प्लांट आराम के दौरान अचानक गलत व्यवहार करेगा।

यह वास्तव में ड्रेनफिल्टर के भोलेपन से पता लगाने के खिलाफ एक सम्मोहक तर्क है कि क्या वर्तमान धागा घबरा रहा है।

drain_filter शब्दावली मेरे लिए सबसे अधिक बनाती है। यह देखते हुए कि हमारे पास पहले से ही सभी वस्तुओं को हटाने के लिए drain है, यह चुनना कि कौन से आइटम को हटाना है filter होगा। जब एक साथ जोड़ा जाता है तो नामकरण बहुत सुसंगत लगता है।

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

एक vec::DrainFilter को समय से पहले छोड़ना वैसे ही व्यवहार करना जारी रखता है जैसे कि यह पूरी तरह से उपभोग किया गया था (जो कि vec::Drain जैसा ही है)। यदि vec::Drain::drop के दौरान विधेय घबराहट होती है, तो शेष आइटम सामान्य रूप से वापस स्थानांतरित हो जाते हैं, लेकिन कोई और आइटम नहीं छोड़ा जाता है और विधेय को फिर से नहीं कहा जाता है। यह अनिवार्य रूप से वही व्यवहार करता है, भले ही विधेय में घबराहट सामान्य खपत के दौरान हो या जब vec::DrainFilter गिरा हो।

यह मानते हुए कि साउंडनेस होल के लिए फिक्स सही है, इस सुविधा के स्थिरीकरण को और क्या रोक रहा है?

क्या Vec::drain_filter को LinkedList::drain_filter से स्वतंत्र रूप से स्थिर किया जा सकता है?

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

यह वास्तव में स्पष्ट नहीं है कि "फ़िल्टर किए गए" आइटम किस तरफ जाते हैं

Vec::drain एक मिसाल कायम करता है। आप उन आइटम्स की श्रेणी निर्दिष्ट करते हैं जिन्हें आप _remove_ करना चाहते हैं। Vec::drain_filter उसी तरह से काम करता है। आप उन वस्तुओं की पहचान करते हैं जिन्हें आप _निकालना चाहते हैं।

और यह वास्तव में स्पष्ट नहीं है कि "फ़िल्टर किए गए" आइटम किस तरफ जाते हैं

मेरी राय है कि यह Iterator::filter के लिए पहले से ही सच है, इसलिए जब भी मैं इसका उपयोग करता हूं तो दस्तावेज़ों को देखने/एक परीक्षण लिखने के लिए मैंने खुद को इस्तीफा दे दिया है। मैं drain_filter के लिए ऐसा नहीं मानता।

काश हमने रूबी की select और reject शब्दावली को चुना होता, लेकिन वह जहाज लंबे समय से रवाना हुआ है।

इस पर कोई प्रगति? क्या नाम ही एकमात्र ऐसी चीज है जो अभी भी अधर में है?

क्या इसे स्थिर होने से कोई रोक रहा है?

ऐसा लगता है कि DrainFilter का Drop impl यदि उनके किसी भी विध्वंसक ने विधेय आतंक से घबराया तो वस्तुओं को लीक कर देगा। यह https://github.com/rust-lang/rust/issues/52267 का मूल कारण है। क्या हमें यकीन है कि हम इस तरह के एपीआई को स्थिर करना चाहते हैं?

कोई बात नहीं, यह स्पष्ट रूप से https://github.com/rust-lang/rust/pull/61224 द्वारा तय किया गया था।

इस ट्रैकिंग मुद्दे पर भी थोड़ा ध्यान देंगे, इस सुविधा को स्थिर होते देखना पसंद करेंगे :D क्या कोई अवरोधक हैं?

सीसी @ डायलन-डीपीसी

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

मुझे लगता है कि यह अधिक बहुमुखी होगा:

fn drain_filter_map<F>(&mut self, f: F) -> DrainFilterMap<T, F> where F: FnMut(T) -> Option<T>

लगभग, अधिक सामान्य संस्करण में FnMut(T) -> Option<U> लगेगा, जैसे Iterator::{filter_map, find_map, map_while} करते हैं। मुझे नहीं पता कि इस तरह से filter_map को सामान्यीकृत करना उचित है, लेकिन यह विचार करने योग्य हो सकता है।

मैं यहां इसलिए आया क्योंकि मैं कमोबेश ठीक उसी तरह से देख रहा था जैसे @jethrogb ने ऊपर सुझाई गई विधि:

fn drain_filter_map<F>(&mut self, f: F) -> DrainFilterMap<T, F>
    where F: FnMut(T) -> Option<T>

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

लगभग, अधिक सामान्य संस्करण में FnMut(T) -> Option<U> लगेगा, जैसे Iterator::{filter_map, find_map, map_while} करते हैं। मुझे नहीं पता कि इस तरह से filter_map को सामान्यीकृत करना उचित है, लेकिन यह विचार करने योग्य हो सकता है।

फ़ंक्शन को Option<T> वापस करना पड़ता है क्योंकि इसके द्वारा उत्पादित मान Vec<T> में संग्रहीत होते हैं।

@ johnw42 मुझे यकीन नहीं है कि मैं अनुसरण करता हूं, क्या Some मूल्य तुरंत पुनरावर्तक द्वारा प्राप्त नहीं किया जाएगा?

वास्तव में, मुझे लगता है कि उस फ़ंक्शन का इनपुट मूल्य अभी भी &T या &mut T के बजाय T होना चाहिए, यदि आप इसे समाप्त नहीं करना चाहते हैं। या हो सकता है कि फ़ंक्शन FnMut(T) -> Result<U, T> जैसा कुछ हो। लेकिन मैं यह नहीं देखता कि आइटम प्रकार किसी अन्य प्रकार का क्यों नहीं हो सकता।

@timvermeulen मुझे लगता है कि हम प्रस्ताव को अलग तरह से व्याख्या कर रहे हैं।

जिस तरह से मैंने इसकी व्याख्या की, Some मान को वापस Vec में संग्रहीत किया जाता है, और None का अर्थ है कि मूल मान पुनरावर्तक द्वारा प्राप्त किया जाता है। यह बंद करने की अनुमति देता है या तो मूल्य को अद्यतन करने के लिए, या इसे Vec से बाहर ले जाने की अनुमति देता है। इसे लिखने में, मुझे एहसास हुआ कि मेरा संस्करण वास्तव में कुछ भी नहीं जोड़ता है क्योंकि आप इसे drain_filter के संदर्भ में कार्यान्वित कर सकते हैं:

fn drain_filter_map<F>(
    &mut self,
    mut f: F,
) -> DrainFilter<T, impl FnMut(&mut T) -> bool>
where
    F: FnMut(&T) -> Option<T>,
{
    self.drain_filter(move |value| match f(value) {
        Some(new_value) => {
            *value = new_value;
            false
        }
        None => true,
    })
}

इसके विपरीत, मैं सोच रहा था कि आपकी व्याख्या बहुत उपयोगी नहीं है क्योंकि यह drain_filter के परिणाम को मैप करने के बराबर है, लेकिन मैंने इसे लिखने की कोशिश की, और ऐसा नहीं है, इसी कारण से filter_map है' t filter के बाद map पर कॉल करने के बराबर है।

@ johnw42 आह, हाँ, मैंने सोचा था कि आप None का मतलब चाहते थे कि मूल्य Vec में रहना चाहिए।

तो ऐसा लगता है कि FnMut(T) -> Result<U, T> सबसे सामान्य होगा, हालांकि यह शायद बहुत ही एर्गोनोमिक नहीं है। FnMut(&mut T) -> Option<U> वास्तव में एक विकल्प नहीं है क्योंकि यह आपको सामान्य स्थिति में T का स्वामित्व लेने की अनुमति नहीं देगा। मुझे लगता है कि FnMut(T) -> Result<U, T> और FnMut(&mut T) -> bool ही एकमात्र विकल्प हैं।

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

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

drain के साथ, आपको निम्नलिखित अच्छे गुण मिलते हैं:

• तत्वों के किसी भी सन्निहित चयन को हटाया जा सकता है।
• हटाए गए आइटम को छोड़ना उतना ही सरल है जितना कि लौटाए गए इटरेटर को छोड़ना।
• हटाए गए आइटम को गिराने की आवश्यकता नहीं है; कॉल करने वाला प्रत्येक व्यक्ति की व्यक्तिगत रूप से जांच कर सकता है और चुन सकता है कि इसके साथ क्या करना है।
• Vec की सामग्री को Copy या Clone का समर्थन करने की आवश्यकता नहीं है।
• Vec के लिए कोई स्मृति आवंटित या मुक्त करने की आवश्यकता नहीं है।
• Vec में बचे मानों को अधिकतम एक बार स्थानांतरित किया जाता है।

drain_filter के साथ, आप Vec से आइटमों के मनमाने सेट को निकालने की क्षमता हासिल करते हैं, न कि केवल एक सन्निहित श्रेणी से। एक कम स्पष्ट लाभ यह है कि यदि वस्तुओं की एक सन्निहित श्रेणी को हटा दिया जाता है, तब भी drain_filter एक प्रदर्शन को बढ़ावा दे सकता है यदि drain को पास करने के लिए सीमा खोजने में Vec पर एक अलग पास बनाना शामिल होगा &mut T है, Vec में छोड़े गए आइटम को अपडेट करना भी संभव है। हुर्रे!

यहां कुछ अन्य चीजें हैं जो आप drain_filter जैसे इन-प्लेस ऑपरेशन के साथ करना चाहेंगे:

1. हटाए गए आइटम को पुनरावर्तक के माध्यम से वापस करने से पहले उन्हें रूपांतरित करें।
2. ऑपरेशन को जल्दी बंद करें और एक त्रुटि की रिपोर्ट करें।
3. आइटम को केवल हटाने या उसे जगह में छोड़ने के बजाय (संभवतः इसे बदलते समय), आइटम को हटाने और इसे एक नए मान से बदलने की क्षमता जोड़ें (जो मूल मूल्य का क्लोन हो सकता है, या पूरी तरह से कुछ और हो सकता है)।
4. हटाए गए आइटम को कई नए आइटम से बदलें।
5. वर्तमान वस्तु के साथ कुछ करने के बाद, निम्नलिखित मदों में से कुछ को छोड़ दें, उन्हें जगह पर छोड़ दें।
6. वर्तमान आइटम के साथ कुछ करने के बाद, पहले निरीक्षण किए बिना कुछ निम्न आइटम हटा दें।

और यहाँ प्रत्येक का मेरा विश्लेषण है:

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

मुझे लगता है कि हम 4 मामलों के साथ एक एनम को बंद करके आवश्यक उपयोग के मामलों का समर्थन कर सकते हैं:

fn super_drain(&mut self, f: F) -> SuperDrainIter<T>
    where F: FnMut(&mut T) -> DrainAction<T>;

enum DrainAction<T>  {
    /// Leave the item in the Vec and don't return anything through
    /// the iterator.
    Keep,

    /// Remove the item from the Vec and return it through the
    /// iterator.
    Remove,

    /// Remove the item from the Vec, return it through the iterator,
    /// and swap a new value into the location of the removed item.
    Replace(T),

    /// Leave the item in place, don't return any more items through
    /// the iterator, and don't call the closure again.
    Stop,
}

एक आखिरी विकल्प जो मैं प्रस्तुत करना चाहता हूं वह है इटरेटर से पूरी तरह से छुटकारा पाना, आइटम को मूल्य से बंद करने के लिए पास करना, और कॉलर को किसी आइटम को अपने साथ बदलकर अपरिवर्तित छोड़ने की अनुमति देना है:

fn super_drain_by_value(&mut self, f: F)
    where F: FnMut(T) -> DrainAction<T>;

enum DrainAction<T>  {
    /// Don't replace the item removed from the Vec.
    Remove,

    /// Replace the item removed from the Vec which a new item.
    Replace(T),

    Stop,
}

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

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

@ johnw42 आप पहले से ही 3 कर सकते हैं। यदि आपके पास एक परिवर्तनीय संदर्भ है, तो mem::replace या mem::take का उपयोग करके।

@johnw42 @jplatte

(3) केवल तभी वास्तव में समझ में आता है जब हम लौटाए गए Iterator के आइटम प्रकार को संग्रह के आइटम प्रकार से अलग होने की अनुमति देते हैं।
(3) एक विशेष मामला है, क्योंकि आप दोनों Iterator तत्व वापस करते हैं, और एक नया तत्व वापस Vec में डालते हैं।

बाइकशेडिंग: मैं Replace(T) के फ़ंक्शन को उलट दूंगा और इसे PushOut(T) बदल दूंगा, जिसका उद्देश्य PushOut के आंतरिक मूल्य को "सबमिट" करना है। Vec में मूल (पैरामीटर) आइटम।

Stop शायद Error प्रकार वापस करने की क्षमता होनी चाहिए (या try_fold तरह थोड़ा सा काम करें?)

मैंने कल रात अपना super_drain_by_value समारोह लागू किया, और मैंने कई चीजें सीखीं।

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

कोड जनरेशन के संदर्भ में, मैंने पाया कि आसान मामलों में (उदाहरण के लिए Vec<i32> ), Vec में और बाहर अनावश्यक चालें एक गैर-मुद्दा हैं, और उस राशि को साधारण चीजों की तरह कहते हैं एक नो-ऑप या Vec को छोटा करना कोड में तब्दील हो जाता है जिसे सुधारना बहुत आसान है (क्रमशः शून्य और तीन निर्देश)। बुरी खबर यह है कि कठिन मामलों के लिए, मेरा प्रस्ताव और drain_filter पद्धति दोनों ही बहुत अधिक अनावश्यक नकल करते हैं, मोटे तौर पर तरीकों के उद्देश्य को हराते हैं। मैंने Vec<[u8; 1024]> के लिए जेनरेट किए गए असेंबली कोड को देखकर इसका परीक्षण किया, और दोनों मामलों में, प्रत्येक पुनरावृत्ति में memcpy पर दो कॉल हैं जिन्हें अनुकूलित नहीं किया गया है। यहां तक ​​कि एक नो-ऑप कॉल भी पूरे बफर को दो बार कॉपी कर देती है!

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

मैंने DrainAction::Stop को R मूल्य ले जाने के लिए विस्तारित करने का भी प्रयास किया जो super_drain_by_value से super_drain_by_value Option<R> रूप में लौटाया गया है, और यह और भी बदतर है, क्योंकि (संभवतः सामान्य) ऐसे मामले में जहां लौटाए गए मूल्य की आवश्यकता नहीं है, संकलक R अनुमान नहीं लगा सकता है और आपको उस मूल्य के प्रकार को स्पष्ट रूप से एनोटेट करना होगा जिसका आप उपयोग भी नहीं कर रहे हैं। इस कारण से, मुझे नहीं लगता कि super_drain_by_value के कॉलर को क्लोजर से मूल्य वापस करने का समर्थन करना एक अच्छा विचार है; यह मोटे तौर पर समान है कि क्यों loop {} निर्माण एक मूल्य वापस कर सकता है, लेकिन किसी अन्य प्रकार का लूप () का मूल्यांकन करता है।

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

एपीआई को थोड़ा और अधिक अनुकूल बनाने के लिए, मुझे लगता है कि क्लोजर रिटर्न () बनाना और इसे एक सहायक वस्तु पास करना बेहतर विकल्प होगा (जिसे मैं यहां "अपडेटर" के रूप में संदर्भित करूंगा) जो हो सकता है Vec के प्रत्येक तत्व का निरीक्षण करने और उसके साथ क्या होता है इसे नियंत्रित करने के लिए उपयोग किया जाता है। इन विधियों के परिचित नाम हो सकते हैं जैसे borrow , borrow_mut , और take , अतिरिक्त विधियों जैसे keep_next(n) या drop_remainder() के साथ। इस तरह के एपीआई का उपयोग करना, साधारण मामलों में बंद करना बहुत आसान है और जटिल मामलों में अधिक जटिल नहीं है। अपडेटर के अधिकांश तरीकों के मूल्य के आधार पर self लेने से, कॉलर को take को एक से अधिक बार कॉल करने, या बाद के पुनरावृत्तियों में क्या करना है, इसके लिए परस्पर विरोधी निर्देश देने जैसी चीजों को करने से रोकना आसान है।

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

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

यहाँ एक बहुत ही काल्पनिक उदाहरण दिया गया है जो कुछ चीजें दिखा रहा है जो एक ज़िप कर सकता है:

/// Keep the first 100 items of `v`.  In the next 100 items of `v`,
/// double the even values, unconditionally keep anything following an
/// even value, discard negative values, and move odd values into a
/// new Vec.  Leave the rest of `v` unchanged.  Return the odd values
/// that were removed, along with a boolean flag indicating whether
/// the loop terminated early.
fn silly(v: &mut Vec<i32>) -> (bool, Vec<i32>) {
    let mut odds = Vec::new();
    // Create a zipper, which get exclusive access to `v`.
    let mut z = v.zipper();
    // Skip over the first 100 items, leaving them unchanged.
    z.keep_next(100);
    let stopped_early = loop {
        if let Some(item /* &mut i32 */) = z.current_mut() {
            if *item < 0 {
                // Discard the value and advance the zipper.
                z.take();
            } else if *item % 2 == 0 {
                // Update the item in place.
                *item *= 2;

                // Leave the updated item in `v`.  This has the
                // side-effect of advancing `z` to the next item.
                z.keep();

                // If there's another value, keep it regardless of
                // what it is.
                if z.current().is_some() {
                    z.keep();
                }
            } else {
                // Move an odd value out of `v`.
                odds.push(z.take());
            }
            if z.position() >= 200 {
                // This consumes `z`, so we must break out of the
                // loop!
                z.keep_rest();
                break true;
            }
        } else {
            // We've reached the end of `v`.
            break false;
        }
    }
    (stopped_early, odds)

    // If the zipper wasn't already consumed by calling
    // `z.keep_rest()`, the zipper is dropped here, which will shift
    // the contents of `v` to fill in any gaps created by removing
    // values.
}

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

fn drain_filter_silly(v: &mut Vec<i32>) -> (bool, Vec<i32>) {
    let mut position: usize = 0;
    let mut keep_next = false;
    let mut stopped_early = false;
    let removed = v.drain_filter(|item| {
        position += 1;
        if position <= 100 {
            false
        } else if position > 200 {
            stopped_early = true;
            false
        } else if keep_next {
            keep_next = false;
            false
        } else if *item >= 0 && *item % 2 == 0 {
            *item *= 2;
            false
        } else {
            true
        }
    }).filter(|item| item >= 0).collect();
    (stopped_early, removed)
}

@ johnw42 आपकी पिछली पोस्ट ने मुझे scanmut क्रेट की याद दिला दी, विशेष रूप से Remover संरचना , और आपके द्वारा उल्लिखित "ज़िपर" अवधारणा बहुत समान लगती है! यह उस विधि की तुलना में बहुत अधिक एर्गोनोमिक प्रतीत होता है जो जब आप कुल नियंत्रण चाहते हैं तो बंद हो जाता है।

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

@timvermeulen मुझे लगता है कि RangeBounds पैरामीटर जोड़ना समझ में आता है, लेकिन वर्तमान क्लोजर हस्ताक्षर ( F: FnMut(&mut T) -> bool ) रखें।
आप ड्रेन किए गए तत्वों को filter_map या जो भी आप चाहते हैं, के साथ हमेशा पोस्ट-प्रोसेस कर सकते हैं।
(मेरे लिए, यह बहुत महत्वपूर्ण है कि क्लोजर तत्व को बदलने की अनुमति देता है, क्योंकि retain इसकी अनुमति नहीं देता है (इस गलती की खोज से पहले इसे स्थिर कर दिया गया था)।)

हाँ, यह सुविधा और उपयोगिता के बीच सही संतुलन प्रतीत होता है।

@timvermeulen हाँ, मैं मुख्य विषय से बहुत दूर भटक रहा था।

एक बात जो मैंने देखी है जो मूल विषय के लिए प्रासंगिक है वह यह है कि यह याद रखना कठिन है कि क्लोजर के रिटर्न वैल्यू का क्या मतलब है - क्या यह कह रहा है कि आइटम को रखना है या इसे हटाना है? मुझे लगता है कि डॉक्स के लिए यह बताना मददगार होगा कि v.drain_filter(p) साइड-इफेक्ट्स के साथ v.iter().filter(p) के बराबर है।

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

सटीक शब्दों के लिए, मैं filter पैरामीटर का नाम बदलकर predicate (मिलान करने के लिए Iterator::filter ) और इस वाक्य को विवरण में कहीं जोड़ने का प्रस्ताव करता हूं:

यह याद रखने के लिए कि predicate के वापसी मूल्य का उपयोग कैसे किया जाता है, यह ध्यान में रखना उपयोगी हो सकता है कि drain_filter Iterator::filter के समान है, चयनित को हटाने के अतिरिक्त दुष्प्रभाव के साथ self से आइटम।

@ जॉन 42 हाँ, अच्छी बात है। मुझे लगता है कि drain_where जैसा नाम ज्यादा स्पष्ट होगा।

यदि आप बाइक शेडिंग का नामकरण करने जा रहे हैं; कृपया सुनिश्चित करें कि आपने सभी टिप्पणियां पढ़ ली हैं; छिपे हुए भी। कई प्रकार पहले ही प्रस्तावित किए जा चुके हैं, जैसे https://github.com/rust-lang/rust/issues/43244#issuecomment -331559537

लेकिन... इसका नाम draintain() होना चाहिए! कोई और नाम उतना सुंदर नहीं है!

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

नामकरण

मेरे द्वारा प्रस्तावित नामों का एक गैर-विचारणीय सारांश यहां दिया गया है:

• drain_filter : वर्तमान कार्यान्वयन में प्रयुक्त नाम। filter_map जैसे अन्य नामों के अनुरूप। drain().filter() के अनुरूप होने का लाभ है, लेकिन अधिक दुष्प्रभावों के साथ।
• drain_where : यह इंगित करने का लाभ है कि true परिणाम _out_ या फ़िल्टरिंग _in_ को निकालने में होता है, जिसे अन्य नामों से याद रखना मुश्किल हो सकता है। std में _where प्रत्यय के लिए कोई मिसाल नहीं है, लेकिन समान प्रत्ययों के लिए बहुत सारे उदाहरण हैं।
• drain().where() की भिन्नता, क्योंकि where पहले से ही एक कीवर्ड है।
• drain_retain : retain के अनुरूप, लेकिन retain और drain में क्लोजर द्वारा लौटाए गए बूलियन मानों की विपरीत व्याख्याएं हैं, जो भ्रमित हो सकती हैं।
• filtered_drain
• drain_if
• drain_when
• remove_if

मापदंडों

drain के साथ संगतता के लिए श्रेणी तर्क जोड़ने लायक हो सकता है।

दो क्लोजर प्रारूप सुझाए गए हैं, FnMut(&mut T) -> bool और FnMut(T) -> Result<T, U> । उत्तरार्द्ध अधिक लचीला है, लेकिन यह भी बेकार है।

$#$22$# retain के अनुरूप होने के लिए बूलियन स्थिति ( true का अर्थ है " Vec में रखें") को उलटने पर चर्चा की गई, लेकिन तब यह drain के अनुरूप नहीं होगा true का अर्थ है " Vec से नाली")।

तनाव मुक्त

जब फ़िल्टर बंद हो जाता है, तो DrainFilter पुनरावर्तक गिरा दिया जाता है। इसके बाद पुनरावर्तक को Vec की निकासी समाप्त करनी चाहिए, लेकिन ऐसा करने के लिए उसे डबल पैनिक को जोखिम में डालते हुए, फ़िल्टर को फिर से बंद करना होगा। कुछ समाधान हैं, लेकिन वे सभी समझौता हैं:

• बूंद पर नाली खत्म मत करो। find या all जैसे एडेप्टर के साथ उपयोग किए जाने पर यह बहुत उल्टा है। इसके अलावा, यह v.drain_filter(...); मुहावरे को बेकार कर देता है क्योंकि इटरेटर आलसी होते हैं।

• ड्रेनिंग को हमेशा ड्रॉप पर खत्म करें। यह डबल पैनिक का जोखिम उठाता है (जिसके परिणामस्वरूप गर्भपात होता है), लेकिन व्यवहार को सुसंगत बनाता है।

• केवल ड्रॉप पर ड्रेनिंग खत्म करें यदि वर्तमान में अनइंडिंग नहीं है। यह पूरी तरह से डबल पैनिक को ठीक करता है, लेकिन drain_filter के व्यवहार को अप्रत्याशित बनाता है: एक विध्वंसक में DrainFilter को गिराना _कभी-कभी वास्तव में अपना काम नहीं कर सकता है।

• अगर फिल्टर बंद होने से घबराहट नहीं हुई तो केवल ड्रॉप पर ड्रेनिंग खत्म करें। यह drain_filter द्वारा किया गया वर्तमान समझौता है। इस दृष्टिकोण की एक अच्छी संपत्ति यह है कि फिल्टर "शॉर्ट-सर्किट" बंद होने में घबराहट होती है, जो यकीनन काफी सहज है।

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

ड्रेन-ऑन-ड्रॉप

DrainIter या तो स्रोत वेक्टर को गिराने पर समाप्त कर सकता है, या यह केवल तभी निकल सकता है जब next कहा जाता है (आलसी पुनरावृत्ति)।

ड्रेन-ऑन-ड्रॉप के पक्ष में तर्क:

• drain के व्यवहार के अनुरूप।

• अन्य एडेप्टर जैसे all , any , find , आदि के साथ अच्छी तरह से इंटरैक्ट करता है...

• vec.drain_filter(...); मुहावरे को सक्षम करता है।

• आलसी कार्यक्षमता को स्पष्ट रूप से drain_lazy -स्टाइल विधियों या lazy() एडाप्टर के माध्यम से DrainIter (और यहां तक ​​कि Drain पर भी सक्षम किया जा सकता है, क्योंकि यह बैकवर्ड-संगत है तरीके जोड़ें)।

आलसी पुनरावृत्ति के पक्ष में तर्क:

• लगभग सभी अन्य पुनरावृत्तियों के अनुरूप।

• "ड्रेन-ऑन-ड्रॉप" कार्यक्षमता को DrainIter पर एडेप्टर के माध्यम से, या यहां तक ​​कि एक सामान्य Iterator::exhausting एडेप्टर के माध्यम से भी स्पष्ट रूप से सक्षम किया जा सकता है (देखें RFC #2370 )।

हो सकता है कि मुझे कुछ सामान छूट गया हो, लेकिन कम से कम मुझे आशा है कि यह धागे को स्किम करते समय नए लोगों की मदद करता है।

@negamartin

क्या drain-on-drop विकल्प की आवश्यकता नहीं होगी कि इटरेटर स्वामित्व वाले मूल्य के बजाय आइटम का संदर्भ देता है? मुझे लगता है कि एक विशिष्ट स्थिति से मेल खाने वाली वस्तुओं को हटाने और स्वामित्व लेने के लिए एक तंत्र के रूप में drain_filter का उपयोग करना असंभव हो जाएगा (जो मेरा मूल उपयोग-मामला था)।

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

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

विशेष रूप से, इसके बीच का अंतर है:

let mut v = vec![1, 5, 3, 6, 4, 7];
v.drain_where(|e| *e > 4).find(|e| *e == 6);

// Drain-on-drop
assert_eq!(v, &[1, 3, 4]);

// Lazy
assert_eq!(v, &[1, 3, 4, 7]);

बस एक विचार फेंकना, लेकिन एक और संभावित एपीआई कुछ ऐसा हो सकता है:

 fn drain_filter_into<F, D>(&mut self, filter: F, drain: D)
        where F: FnMut(&mut T) -> bool, 
                   D: Extend<T>
    { ... }

यह अन्य विकल्पों की तुलना में कम लचीला है, लेकिन जब DrainFilter गिरा दिया जाता है तो क्या करना है की समस्या से बचता है।

मुझे ऐसा लगता है कि यह पूरी चीज मुझे कम और कम देख रही है जैसे retain_mut() ( retain() बंद करने के लिए पारित एक परिवर्तनीय संदर्भ के साथ), जो कि यह सबसे पहले और सबसे महत्वपूर्ण प्रदान करने का इरादा था . क्या हम फ़िल्टर्ड ड्रेन चीज़ के डिज़ाइन पर काम करने के अलावा अभी के लिए retain_mut() प्रदान कर सकते हैं? या क्या मैं कुछ न कुछ भूल रहा हूं?

@ बार्टमैसी

यह वही है जो प्रदान करना सबसे पहले और सबसे महत्वपूर्ण था।

मुझे नहीं लगता कि ऐसा है। फ़िल्टर मानदंड के आधार पर आइटम का स्वामित्व लेने के लिए मैं विशेष रूप से drain_filter का उपयोग करता हूं। Drain और DrainFilter उस आइटम को यील्ड करते हैं जहां के रूप में बनाए रखा नहीं है।

@negamartin

बस स्पष्ट होने के लिए, जब मैं ड्रेन-ऑन-ड्रॉप कहता हूं तो मेरा मतलब केवल उस व्यवहार से है जब इटरेटर पूरी तरह से खपत नहीं होता है

आह अच्छा। यही मेरी गलती है। मैंने आपकी परिभाषा को गलत समझा। मैंने इसकी व्याख्या इस प्रकार की थी कि "vec से कुछ भी नहीं हटाया जाता है जब तक कि गिराया नहीं जाता", जिसका वास्तव में कोई मतलब नहीं है।

आलसी पुनरावृत्ति के पक्ष में तर्क

मुझे लगता है कि इसे drain के अनुरूप होना चाहिए। Iterator::exhausting RFC को स्वीकार नहीं किया गया था और यह बहुत अजीब होगा यदि drain और drain_filter में नाली के व्यवहार के विपरीत प्रतीत होता है।

@negamartin

ड्रेन_फिल्टर: वर्तमान कार्यान्वयन में प्रयुक्त नाम। फ़िल्टर_मैप जैसे अन्य नामों के अनुरूप। drain().filter() के अनुरूप होने का लाभ है, लेकिन अधिक दुष्प्रभावों के साथ।

यह समान नहीं है (इसीलिए हमें retain_mut / drain_filter की आवश्यकता है):
drain().filter() उन तत्वों को भी समाप्त कर देगा जिनके लिए फ़िल्टर बंद होने से false !

मैंने #RFC 2870 में lib टीम द्वारा एक टिप्पणी में एक छोटी सी रेखा देखी:

संभावनाओं में इसे सामान्य, या एक बिल्डर पैटर्न बनाकर एक विधि "ओवरलोडिंग" शामिल हो सकती है।

यदि यह अभी भी पिछले ठोस प्रकार को स्वीकार करता है तो क्या यह सामान्य विधि बनाने के लिए पीछे की ओर संगत है? अगर ऐसा है, तो मेरा मानना ​​है कि यह आगे बढ़ने का सबसे अच्छा तरीका होगा।

(बिल्डर पैटर्न इटरेटर्स के साथ थोड़ा अनपेक्षित है, क्योंकि इटरेटर पर विधियां आमतौर पर एडेप्टर होती हैं, व्यवहार-परिवर्तक नहीं। इसके अलावा, कोई मिसाल नहीं है, उदाहरण के लिए chunks और chunks_exact दो अलग-अलग तरीके हैं। , chunks().exact() कॉम्बो नहीं।)

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

शुक्र, जून 12, 2020, 21:21 negamartin [email protected] पर लिखा है:

मैंने अभी-अभी #RFC 2870 . में lib टीम की एक टिप्पणी में एक छोटी सी पंक्ति देखी है
https://github.com/rust-lang/rfcs/pull/2369 :

संभावनाओं में इसे सामान्य बनाकर एक विधि "ओवरलोडिंग" शामिल हो सकती है,
या एक बिल्डर पैटर्न।

क्या यह एक विधि को सामान्य बनाने के लिए पीछे की ओर संगत है यदि यह अभी भी स्वीकार करता है
पिछले ठोस प्रकार? अगर ऐसा है, तो मेरा मानना ​​है कि यह सबसे अच्छा तरीका होगा
आगे।

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

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

यदि यह अभी भी पिछले ठोस प्रकार को स्वीकार करता है तो क्या यह सामान्य विधि बनाने के लिए पीछे की ओर संगत है? अगर ऐसा है, तो मेरा मानना ​​है कि यह आगे बढ़ने का सबसे अच्छा तरीका होगा।

नहीं, क्योंकि यह कुछ मामलों में टाइप अनुमान को तोड़ता है। उदाहरण के foo.method(bar.into()) एक ठोस प्रकार के तर्क के साथ काम करेगा, लेकिन सामान्य तर्क के साथ नहीं।

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

drain_filter() के साथ जो कुछ भी होता है, उससे स्वतंत्र, retain_mut() को जोड़ने का प्रयास करने के लिए मुझे कौन सी प्रक्रिया शुरू करने की आवश्यकता है? मुझे ऐसा लगता है कि आवश्यकताएं अलग हो गई हैं, और यह कि retain_mut() अभी भी उपयोगी होगा, भले ही drain_filter() के साथ कुछ भी हो।

नए अस्थिर पुस्तकालय एपीआई के लिए @ बार्टमैसी , मुझे लगता है कि कार्यान्वयन के साथ पीआर बनाना ठीक होना चाहिए। सुविधा को लागू करने के लिए https://rustc-dev-guide.rust-lang.org/implementing_new_features.html पर और https://rustc-dev-guide.rust-lang.org/getting-started.html पर निर्देश हैं। अपने परिवर्तनों के परीक्षण के लिए #बिल्डिंग-एंड-टेस्टिंग-

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

उदाहरण के लिए String, Vec, HashMap, HashSet, BinaryHeap और VecDeque में retain विधि है, लेकिन LinkedList और BTreeMap नहीं है। मुझे यह विशेष रूप से अजीब लगता है क्योंकि retain एक लिंक्डलिस्ट या मानचित्र के लिए वैक्टर की तुलना में अधिक प्राकृतिक विधि की तरह लगता है जहां यादृच्छिक विलोपन एक बहुत महंगा ऑपरेशन है।

और जब आप थोड़ा गहरा खोदते हैं तो यह और भी अधिक हैरान करने वाला होता है: HashMap::retain के क्लोजर को एक परिवर्तनशील संदर्भ में मान दिया जाता है, लेकिन अन्य संग्रहों को एक अपरिवर्तनीय संदर्भ मिलता है (और स्ट्रिंग को एक साधारण char मिलता है )

अब मैं देखता हूं कि drain_filter जैसे नए एपीआई जोड़े जा रहे हैं जो 1/ retain के साथ ओवरलैप होने लगते हैं और 2/ एक ही समय में सभी संग्रहों के लिए स्थिर नहीं होते हैं:

• HashMap::drain_filter अपस्ट्रीम रेपो में है लेकिन अभी तक रस्ट के एसटीडी AFAIK के साथ शिप नहीं किया गया है (यह डॉक्स में प्रकट नहीं होता है)
• BTreeMap::drain_filter , Vec::drain_filter , LinkedList::drain_filter रस्ट के एसटीडी में हैं, लेकिन फीचर गेटेड हैं
• VecDeque::drain_filter बिल्कुल मौजूद नहीं प्रतीत होता है, यह दस्तावेज़ों में प्रकट नहीं होता है
• String::drain_filter या तो मौजूद नहीं है

इन सुविधाओं को लागू करने के सर्वोत्तम तरीके के बारे में मेरी कोई मजबूत राय नहीं है, या यदि हमें drain_filter , retain या दोनों की आवश्यकता है, लेकिन मेरा बहुत दृढ़ विश्वास है कि ये API सभी संग्रहों में एक समान रहना चाहिए .

और शायद इससे भी महत्वपूर्ण बात यह है कि विभिन्न संग्रहों के समान तरीकों में समान शब्दार्थ होना चाहिए। कुछ ऐसा जो retain के वर्तमान कार्यान्वयन IMO का उल्लंघन करते हैं।