क्या Clone की आवश्यकता के बिना रूपांतरण विफल होने पर मूल मूल्य के साथ एक त्रुटि को सामान्य रूप से मुद्रित करने का कोई तरीका है, इसलिए एक संबंधित विधि जो विफलता पर घबराहट में अच्छा त्रुटि संदेश हो सकती है?

यह प्रस्तावना में जाना चाहिए या नहीं, इस पर चर्चा लंबित है जब यह स्थिर हो जाएगा।

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

हम इसे अगले चक्र के लिए चर्चा के लिए ला सकते हैं।

यह मुद्दा अब स्थिरीकरण के लिए एक चक्र-लंबी अंतिम टिप्पणी अवधि में प्रवेश कर रहा है 🔔

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

इन लक्षणों के उद्देश्य के बारे में मेरे कुछ प्रश्न हैं।

1. इन्हें std में किस प्रकार के लिए लागू किया जाएगा?
2. impl TryFrom<T> for T जैसे कार्यान्वयन किस प्रकार प्राप्त करना चाहिए?
3. यदि उनके पास पहले से ही impl From<U> for T है तो किस प्रकार के कार्यान्वयन को impl TryFrom<U> for T मिलना चाहिए?

cc @sfackler , क्या आप इम्प्लस के वर्तमान सेट और कुछ तर्कों पर भी विस्तार कर सकते हैं?

मुझे लगता है कि सामान्य तौर पर अंतर्ज्ञान From / Into के लिए बिल्कुल वैसा ही होना चाहिए, सिवाय इसके कि जब रूपांतरण विफल हो सकता है। जैसे हम मानक पुस्तकालय प्रकारों में धीरे-धीरे From और Into के कार्यान्वयन जोड़ते हैं, मुझे उम्मीद है कि हम TryFrom और TryInto के लिए भी ऐसा ही करेंगे। यहां सबसे महत्वपूर्ण दिशानिर्देश यह है कि रूपांतरण "प्रामाणिक रूप से स्पष्ट" होना चाहिए - यदि एक प्रकार को दूसरे प्रकार में बदलने के लिए एक से अधिक उचित तरीके हैं, तो TryFrom या From सही नहीं हो सकता है उपयोग करने के लिए चीजें।

_सामान्य तौर पर, मुझे नहीं लगता कि यह उम्मीद की जानी चाहिए कि सभी प्रकार impl TryFrom<T> for T हों या मैन्युअल रूप से impl From<U> for T उठाएं। विशेष रूप से, यह अक्सर स्पष्ट नहीं होता है कि कौन सा त्रुटि प्रकार चुनना है। हालांकि, उन प्रकार के कार्यान्वयन बहुत अधिक हैं जिन्हें एक विशेष एपीआई काम करने के लिए परिभाषित किया जा सकता है और परिभाषित किया जाना चाहिए। उदाहरण के लिए, हमारे पास आरएफसी में उल्लिखित कारणों के लिए आदिम पूर्णांक प्रकारों के विभिन्न संयोजनों के लिए इन दोनों प्रकार के कार्यान्वयन हैं। एक अन्य उदाहरण के रूप में, एक तदर्थ विशेषता जो TryFrom / TryInto को प्रतिस्थापित करेगी, वह है postgres::IntoConnectParams , जिसमें ConnectParams को अपने आप में बदलने के लिए एक रिफ्लेक्सिव कार्यान्वयन है।

सामान्य तौर पर, मुझे नहीं लगता कि यह उम्मीद की जानी चाहिए कि सभी प्रकारों को TryFrom<T> for T या मैन्युअल रूप से एक impl From<U> for T उठाना चाहिए।

जब एक TryFrom रूपांतरण अचूक होता है तो त्रुटि प्रकार enum Void {} होना चाहिए, है ना? (या किसी अन्य नाम के साथ एक समान एनम।) जो मुझे एक सामान्य उद्देश्य Void टाइप करने के लिए एक अच्छे कारण की तरह लगता है std ।

@SimonSapin जो IntoConnectParams स्टाइल API और साथ ही RFC में उल्लिखित पूर्णांक रूपांतरण उपयोग केस को तोड़ देगा क्योंकि त्रुटि प्रकार के अचूक और गिरने योग्य रूपांतरण मेल नहीं खाएंगे।

@SimonSapin https://github.com/rust-lang/rfcs/pull/1216

@sfackler यदि आप त्रुटि प्रकारों के लिए सादे From का उपयोग नहीं करते हैं (उदाहरण के लिए try! )! impl<T> From<!> for T उस उद्देश्य के लिए मौजूद हो सकता है और होना चाहिए।

जैसे हम मानक पुस्तकालय प्रकारों में धीरे-धीरे From और Into के कार्यान्वयन जोड़ते हैं, मुझे उम्मीद है कि हम TryFrom और TryInto के लिए भी ऐसा ही करेंगे।

ऐसा लगता है कि ऐसा अभी तक नहीं हुआ है, इसलिए मुझे नहीं पता कि ऐसा इसलिए है क्योंकि कोई भी इसके पास नहीं गया है या std में कोई लागू प्रकार नहीं है। यदि std में लागू प्रकार हैं तो उनके लिए कुछ कार्यान्वयन देखना अच्छा होगा। उदाहरण के लिए निम्नलिखित में से कोई भी अच्छा कार्यान्वयन है?

impl TryFrom<u32> for char
impl TryFrom<char> for u8
impl TryFrom<Vec<u8>> for String
impl TryFrom<&[u8]> for &str

_सामान्य तौर पर, मुझे नहीं लगता कि यह उम्मीद की जानी चाहिए कि सभी प्रकार impl TryFrom<T> for T हों या मैन्युअल रूप से impl From<U> for T उठाएं।

मुद्दा यह है कि यदि आप TryInto<T> का उपयोग करना चाहते हैं और T आपके टोकरे में नहीं है तो आपको केवल यह आशा करनी होगी कि impl TryFrom<T> for T लागू हो गया है। यह एक दुर्भाग्यपूर्ण सीमा है, जो From / Into के लिए मौजूद नहीं है।

@SimonSapin जो IntoConnectParams शैली API और साथ ही RFC में उल्लिखित पूर्णांक रूपांतरण उपयोग के मामले को तोड़ देगा क्योंकि त्रुटि प्रकार के अचूक और गिरने योग्य रूपांतरण मेल नहीं खाएंगे।

क्या इसका मतलब यह है कि आप जिस प्रकार में कनवर्ट कर रहे हैं उसके आधार पर त्रुटि प्रकार किसी भी तरह तय किया गया है?

क्यों TryFrom::Err और TryInto::Err std::error::Error से बंधे नहीं हैं?

एसटीडी द्वारा बाध्य नहीं :: त्रुटि :: त्रुटि?

यह Err को () $ होने से रोकेगा, जो अचूक रूपांतरणों के लिए एक व्यवहार्य त्रुटि प्रकार है।

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

एक बार RFC 1216 लागू हो जाने के बाद, ! अचूक रूपांतरणों के लिए उपयुक्त त्रुटि प्रकार होगा। मैं _थिंक_ इसका मतलब यह होगा कि Error TryFrom::Err / TryInto::Err पर बाध्य Error ठीक रहेगा।

मैं निश्चित रूप से इसे पसंद करूंगा यदि From<T> को लागू करने से TryFrom<T, Err = !> कार्यान्वयन प्राप्त हुआ (और निश्चित रूप से Into के लिए)।

मैं _थिंक_ इसका मतलब यह होगा कि Error पर TryFrom::Err / TryInto::Err पर बाध्य होना ठीक रहेगा।

हाँ, हमारे पास निश्चित रूप से इस प्रकार के मामलों के लिए impl Error for ! { ... } होगा।

मैं पूर्णांक रूपांतरणों के उपयोग के मामले में प्रकार के अंतर के बारे में थोड़ा चिंतित हूं, लेकिन ऐसा लगता है कि हमें शायद इसे ! -as-a-type भूमि तक प्रयोग करने का मौका मिलने तक इसे स्थिर करने पर ध्यान देना चाहिए।

मेरे पीओवी में त्रुटियों का प्रतिनिधित्व करने वाले सभी संबद्ध प्रकारों को Error द्वारा बाध्य किया जाना चाहिए। अफसोस की बात है कि हमने इसके बिना पहले ही एक प्रकार छोड़ दिया है: FromStr::Err (केवल अन्य सार्वजनिक प्रकार TryInto और TryFrom हैं, जिन्हें $#$ ack 'type Err;' और ack 'type Error;' से चेक किया गया है।

हाल ही में चर्चा की गई, libs टीम ने ! प्रकार पर काम किए जाने तक इन लक्षणों को स्थिर करने का प्रयास करने का निर्णय लिया।

मुझे लगता है कि अब यह अवरुद्ध नहीं है, है ना?

@Sfackler के रूप में नामांकन को हटाने से ! प्रकार और इन लक्षणों की जांच की जाएगी।

क्या निकट भविष्य में स्थिर होने के लिए इसमें कोई बदलाव होगा?

क्यों TryFrom::Err और TryInto::Err std::error::Error से बाध्य नहीं है?

std::err::Error #![no_std] बिल्ड में मौजूद नहीं है। साथ ही, कई मामलों में त्रुटि प्रकार के लिए उपलब्ध होने पर भी std::err::Error को लागू करने में कोई लाभ नहीं होता है। इस प्रकार, मैं इस तरह की कोई बाध्यता नहीं रखना पसंद करूंगा।

मैंने इसे स्वयं अपने पुस्तकालय में लागू करने का प्रयोग किया है। मैं https://github.com/rust-lang/rfcs/pull/1542#issuecomment -206804137: try!(x.try_into()); में @SimonSapin द्वारा व्यक्त की गई चिंता को दोहराना चाहता हूं क्योंकि यह भ्रमित करने वाला है क्योंकि "कोशिश" शब्द है एक ही कथन में दो अलग-अलग तरीकों का इस्तेमाल किया।

मैं समझता हूं कि बहुत से लोग कहते हैं कि ऐसी चीजें x.try_into()?; लिखी जानी चाहिए, हालांकि मैं उन लोगों की एक बड़ी संख्या में से एक हूं (सभी बहसों के आधार पर) जो दृढ़ता से ? सिंटैक्स का उपयोग नहीं करना पसंद करते हैं। सभी बहसों में उल्लिखित सभी कारणों के कारण।

व्यक्तिगत रूप से मुझे लगता है कि हमें अभी भी कुछ पैटर्न खोजने की कोशिश करनी चाहिए जिसके लिए नामों पर try_ उपसर्ग की आवश्यकता नहीं है।

मैं नामकरण के बारे में विशेष रूप से दृढ़ता से महसूस नहीं करता, लेकिन मैं व्यक्तिगत रूप से कुछ भी बेहतर नहीं सोच सकता।

Result लौटाने वाले कार्यों के फ्लेवर के लिए try_ का उपयोग करना पहले से ही अर्ध-मानक बन गया है।

हालांकि मैं उन लोगों की एक बड़ी संख्या में से एक हूं (सभी बहसों के आधार पर) जो ? सिंटैक्स का उपयोग नहीं करना पसंद करते हैं क्योंकि ... सभी बहसों में उल्लिखित सभी कारण।

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

लेकिन वह अब अतीत में है। ? स्थिर है और यह दूर नहीं जा रहा है। इसलिए हम सभी भी इसे अपना सकते हैं ताकि हम सभी एक ही चीज़ का उपयोग कर रहे हों और हम try! के साथ नाम के विरोध के बारे में चिंता करना बंद कर सकें।

मैं @SimonSapin द्वारा रस्ट-लैंग/rfcs#1542 में व्यक्त की गई चिंता को दोहराना चाहता हूं (टिप्पणी)

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

इसके अलावा, मुझे लगता है कि बाद के बजाय जल्द ही स्थिर होना दूसरे दौर के नाम बाइकशेडिंग से अधिक महत्वपूर्ण है। RFC को स्वीकार किए कई महीने हो चुके हैं और इसे #[unstable] लागू किया गया है।

परिणाम लौटाने वाले कार्यों के स्वाद के लिए try_ का उपयोग करने के लिए यह पहले से ही अर्ध-मानक बन गया है।

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

साथ ही, मुझे इसे लिखने का कोई व्यावहारिक लाभ नहीं मिला है:

impl TryInto<X> for Y {
    type Err = MyErrorType;

   fn try_into(self) -> Result<X, Self::Err> { ... }
}

इसके बजाए, मैं हमेशा इसे लिख सकता हूं, बहुत कम वाक्य रचनात्मक ओवरहेड:

    fn into_x(self) -> Result<X, MyErrorType> { ... }

मुझे बहुत सारे रूपांतरण होने के बावजूद TryInto या TryFrom द्वारा मानकीकृत किया गया जेनेरिक कोड कभी नहीं लिखना पड़ा, इसलिए बाद वाला फॉर्म मेरे द्वारा परिभाषित प्रकारों में मेरे सभी उपयोगों के लिए पर्याप्त है। मुझे लगता है कि TryInto<...> या TryFrom<...> पैरामीटर संदिग्ध रूप की तरह लगते हैं।

साथ ही, मैंने पाया कि संबंधित त्रुटि प्रकार का नामकरण Err के बजाय Error त्रुटि-प्रवण था क्योंकि मैंने हमेशा Error टाइप किया था। मैंने देखा कि यह गलती आरएफसी के प्रारूपण के दौरान भी की गई थी: https://github.com/rust-lang/rfcs/pull/1542#r60139383। साथ ही, Result का उपयोग करने वाला कोड पहले से ही Err नाम का व्यापक रूप से उपयोग करता है क्योंकि यह Result कंस्ट्रक्टर है।

एक वैकल्पिक प्रस्ताव था जो विशेष रूप से पूर्णांक प्रकारों पर केंद्रित था और "चौड़ा" और "संकीर्ण" जैसी शब्दावली का इस्तेमाल करता था, उदाहरण के लिए x = try!(x.narrow()); जिसे मैंने भी लागू किया था। मैंने पाया कि मेरे वास्तविक उपयोग में प्रस्तावित कार्यक्षमता के मेरे उपयोग के लिए प्रस्ताव पर्याप्त था क्योंकि मैंने केवल अंतर्निर्मित पूर्णांक प्रकारों पर ऐसे रूपांतरण किए। यह उपयोग के मामलों के लिए अधिक एर्गोनोमिक और स्पष्ट (आईएमओ) भी है जो इसके लिए पर्याप्त है।

इसके अलावा, मुझे इसे लिखने का कोई व्यावहारिक लाभ नहीं मिला है ...

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

impl TryInto<TcpStream> for SocketAddr {
    type Err = io::Error;
    fn try_into(self) -> Result<TcpStream, io::Error> {
        TcpStream::connect(self)
    }
}

impl<T> TryInto<MutexGuard<T>> for Mutex<T> {
    type Err = TryLockError<MutexGuard<T>>;
    fn try_into(self) -> Result<Mutex<T>, Self::Err> {
        self.try_lock()
    }
}

impl TryInto<process::Output> for process::Child {
    type Err = io::Error;
    fn try_into(self) -> Result<process::Output, io::Error> {
        self.wait_with_output()
    }
}

impl TryInto<String> for Vec<u8> {
    type Err = FromUtf8Error;
    fn try_into(self) -> Result<String, FromUtf8Error> {
        String::from_utf8(self)
    }
}

यह विशेषता लगभग बहुत सामान्य लगती है। उपरोक्त सभी उदाहरणों में try_into पर कॉल करने के बजाय स्पष्ट रूप से यह कहना बेहतर होगा कि आप वास्तव में क्या कर रहे हैं।

मुझे लगता है कि TryInto<...> या TryFrom<...> पैरामीटर संदिग्ध रूप की तरह लगते हैं।

भी सहमत हैं। फ़ंक्शन को मान पास करने से पहले आप केवल रूपांतरण क्यों नहीं करेंगे और त्रुटि को संभालेंगे?

std::err::Error #![no_std] बिल्ड में मौजूद नहीं है। साथ ही, कई मामलों में उपलब्ध होने पर भी त्रुटि प्रकार के लिए std::err::Error लागू करने में कोई लाभ नहीं होता है। इस प्रकार, मैं इस तरह की कोई बाध्यता नहीं रखना पसंद करूंगा।

std::error::Error से बंधे होने का एक लाभ यह है कि यह किसी अन्य त्रुटि के cause() का वापसी मूल्य हो सकता है। मैं वास्तव में नहीं जानता कि core::error::Error क्यों नहीं है, लेकिन मैंने उस पर ध्यान नहीं दिया है।

साथ ही, मैंने पाया कि त्रुटि के बजाय संबंधित त्रुटि प्रकार Err का नामकरण त्रुटि-प्रवण था क्योंकि मैंने हमेशा त्रुटि टाइप की थी। मैंने देखा कि यह गलती RFC के प्रारूपण के दौरान भी की गई थी: rust-lang/rfcs#1542 (टिप्पणी)। साथ ही, परिणाम का उपयोग करने वाला कोड पहले से ही Err नाम का व्यापक रूप से उपयोग करता है क्योंकि यह एक परिणाम निर्माता है।

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

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

सुसंगत मुद्दों के कारण Error को core में स्थानांतरित नहीं किया जा सकता है।

इसके अलावा समेकन मुद्दों के कारण Box<Error> Error लागू नहीं करता है, एक और कारण है कि हम Err प्रकार को बाध्य नहीं करते हैं।

वास्तव में इसे विशेषता परिभाषा पर बाध्य करने की कोई आवश्यकता नहीं है, वैसे भी - आप बाद में उस बाध्यता को हमेशा जोड़ सकते हैं:

where T: TryInto<Foo>, T::Err: Error

मैं आमतौर पर इन धागों पर टिप्पणी नहीं करता, लेकिन मैं कुछ समय से इसका इंतजार कर रहा था और जैसा कि ऊपर कई लोगों ने व्यक्त किया है, मुझे यकीन नहीं है कि होल्ड अप क्या है; मैं हमेशा एक ऐसी विशेषता चाहता हूं जो विफल हो सकती है। मेरे पास कोड है जिसे try_from कहा जाता है ... यह विशेषता _perfectly_ उस विचार को समाहित करती है। कृपया मुझे इसे स्थिर जंग पर उपयोग करने दें।

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

ऐसा कहा जा रहा है, मेरा मानना ​​​​है कि str::parse इससे बहुत लाभ होगा, क्योंकि यह FromStr विशेषता को बाध्य के रूप में भी माहिर करता है - जो वास्तव में ( TryFrom<str> ) हाथ विशेष है।

तो अगर मैं गलत हूं तो मुझे सुधारें, लेकिन मेरा मानना ​​​​है कि इसे स्थिर करना और इसे str::parse के लिए उपयोग करना:

1. बॉयलरप्लेट पुन: कार्यान्वयन को हटा दें, और इसलिए एक कम परिचित, और विशिष्ट विशेषता को हटा दें
2. हस्ताक्षर में TryFrom<str> जोड़ें, जो ठीक से कन्वर्ट मॉड्यूल में है और अधिक आसानी से स्पष्ट है कि यह क्या करता है
3. अपस्ट्रीम ग्राहकों को उनके डेटा प्रकारों के लिए TryFrom<str> को लागू करने और str.parse::<YourSweetDataType>() मुफ्त में प्राप्त करने की अनुमति देगा, साथ ही अन्य try_from के साथ-साथ वे कार्यान्वयन की तरह महसूस करते हैं, जो बेहतर तार्किक कोड संगठन के लिए बनाता है।

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

1. मुझे एक डिफ़ॉल्ट संस्करण चाहिए; ओह, मुझे SomeType::default() तक पहुंचने दो
2. मैं इसे रूपांतरित करना चाहता हूं, मुझे आश्चर्य है कि SomeType::from(other) लागू किया गया है (आप इसे केवल टाइप कर सकते हैं और देख सकते हैं कि यह दस्तावेज़ीकरण तक पहुंचे बिना संकलित करता है या नहीं)
3. मैं इसे क्लोन करना चाहता हूं, clone()
4. मैं इसे इससे प्राप्त करने का प्रयास करना चाहता हूं, और चूंकि त्रुटियां जंग का एक अभिन्न अंग हैं, यह हस्ताक्षर में विफल हो सकता है, इसलिए मुझे try_from - ओह रुको: पी

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

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

कुछ अर्थों में, यह आपस में एक सज्जन व्यक्ति के समझौते को औपचारिक रूप दे रहा है, और हमारे लिए कुछ परिचित कार्यों को करना आसान और अधिक परिचित बनाता है।

और इसके बारे में मुझे बस इतना ही कहना है;)

अचूक पूर्णांक रूपांतरणों के लिए त्रुटि प्रकार के रूप में ! का उपयोग करने की संभावना की जांच पर इसे पहले रोक दिया गया था। चूंकि यह सुविधा वर्तमान में लागू है, यह सबसे साधारण मामलों में भी विफल हो जाती है: https://is.gd/Ws3K7V।

क्या हम अभी भी विधि के नाम बदलने के बारे में सोच रहे हैं, या हमें इस सुविधा को इसमें रखना चाहिए FCP?

@sfackler वह खेल का मैदान लिंक मेरे लिए काम करता है यदि मैं लाइन 29 पर रिटर्न प्रकार को Result<u32, ()> से Result<u32, !> में बदलता हूं: https://is.gd/A9pWbU यह पहचानने में विफल रहता है कि let Ok(x) = val; एक अकाट्य पैटर्न है जब वैल में Err प्रकार होता है!, लेकिन यह एक अवरुद्ध समस्या की तरह प्रतीत नहीं होता है।

@Ixrec इन लक्षणों के लिए प्राथमिक प्रेरणा सी पूर्णांक टाइपपीफ से और उसके लिए रूपांतरण था। अगर मेरे पास कोई फ़ंक्शन है

fn foo(x: i64) -> Result<c_long, TryFromIntError> {
    x.try_into()
}

यह i686 लक्ष्यों पर संकलित होगा लेकिन x86_64 लक्ष्यों पर नहीं।

इसी तरह, मान लें कि मैं IntoConnectParams प्रकार को बदलना चाहता हूं: https://docs.rs/postgres/0.13.4/postgres/params/trait.IntoConnectParams.html। मैं यह कैसे कर सकता हूँ अगर वहाँ एक कंबल है impl<T> TryFrom<T> for T { type Error = ! } ? मुझे ConnectParams के लिए रिफ्लेक्सिव कार्यान्वयन की आवश्यकता है, लेकिन ! से भिन्न ठोस त्रुटि प्रकार के साथ।

यह पहचानने में विफल रहता है कि let Ok(x) = val; एक अकाट्य पैटर्न है जब वैल में Err प्रकार होता है!

ध्यान दें कि उसके लिए एक पीआर खुला है ।

अगर मेरे पास कोई फ़ंक्शन है ...

हालांकि यह काम करना चाहिए

fn foo(x: i64) -> Result<c_long, TryFromIntError> {
    let val = x.try_into()?;
    Ok(val)
}

कष्टप्रद +1 टिप्पणी होने के जोखिम पर, मैं केवल यह उल्लेख करना चाहता हूं कि मैक्रोज़ 1.1 के रस्ट 1.15 में आने के बाद, try_from रूमा को रात्रिकालीन रस्ट पर रखने वाली अंतिम विशेषता होगी। स्थिर try_from का बेसब्री से इंतजार है!

अधिक महत्वपूर्ण नोट पर ...

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

यह एक अच्छा अवलोकन है, लेकिन मुझे लगता है कि try_ उपसर्ग का कारण यह नहीं है कि वापसी प्रकार को Result के रूप में पहचानना आवश्यक है, लेकिन इसे गैर-गिरने योग्य समकक्ष से अलग करना आवश्यक है।

साथ ही, मैंने पाया कि त्रुटि के बजाय संबंधित त्रुटि प्रकार Err का नामकरण त्रुटि-प्रवण था क्योंकि मैंने हमेशा त्रुटि टाइप की थी। मैंने देखा कि यह गलती RFC के प्रारूपण के दौरान भी की गई थी: rust-lang/rfcs#1542 (टिप्पणी)। साथ ही, परिणाम का उपयोग करने वाला कोड पहले से ही Err नाम का व्यापक रूप से उपयोग करता है क्योंकि यह एक परिणाम निर्माता है।

मैं इस वाले पर सहमत हूं। पुस्तकालयों में मेरे सामने आए अधिकांश अन्य त्रुटि प्रकारों को "त्रुटि" नाम दिया गया है और मुझे यह पसंद है कि अब तक "इर्र" का अर्थ केवल Result::Err है। ऐसा लगता है कि इसे "इरेट" के रूप में स्थिर करने से लोगों को लगातार गलत नाम मिल रहा है (कोई इरादा नहीं है)।

@canndrew बेशक काम करना संभव है, लेकिन इस सुविधा के लिए उस प्रेरणा का पूरा बिंदु इस प्रकार के प्लेटफ़ॉर्म अंतरों को सही ढंग से संभालना आसान बनाना है - हम "x86 पर संकलन लेकिन एआरएम नहीं" के पूरे स्थान से बचना चाहते हैं। .

मुझे लगता है कि मैंने Err को FromStr के साथ संगति के लिए चुना लेकिन मुझे स्थिर होने से पहले Error पर स्विच करने में बहुत खुशी होगी!

रूमा को रात्रिकालीन रस्त पर रखते हुए अंतिम विशेषता

इसी तरह, वैकल्पिक खेल के मैदान के बैकएंड को केवल TryFrom तक पहुंच के लिए रात्रिकालीन आवश्यकता होती है; मेरी पसंद के हिसाब से रात का सर्डे सामान बहुत अस्थिर था, इसलिए मैं बिल्ड स्क्रिप्ट सेटअप में चला गया। 1.15 के साथ, मैं वापस #[derive] पर जाऊँगा। मैं इस सुविधा के स्थिर होने का बेसब्री से इंतज़ार कर रहा हूँ!

@sfackler क्षमा करें मैं अनुसरण नहीं कर रहा था। पूर्णांक रूपांतरणों के मामले में ऐसा लगता है कि प्लेटफॉर्म के आधार पर हमें वास्तव में c_ulong को u32 या u64 पर टाइप करने की आवश्यकता नहीं है बल्कि किसी भी तरह इसे एक नया प्रकार बनाना है। इस तरह TryFrom<c_ulong> impl TryFrom<u{32,64}> impl के साथ हस्तक्षेप नहीं कर सकता है।
आखिरकार, अगर हम अलग-अलग प्लेटफॉर्म पर अलग-अलग प्रकारों को परिभाषित करते हैं, तो हम हमेशा "एक प्लेटफॉर्म को संकलित करते हैं लेकिन दूसरे को नहीं" करते हैं। अन्यथा पूरी तरह से तार्किक TryFrom<T> for U where U: From<T> निहितार्थ का त्याग करना शर्म की बात है ताकि हम संदिग्ध अभ्यास की तरह लगने वाले समर्थन का समर्थन कर सकें।

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

इसी तरह, मान लें कि मैं IntoConnectParams प्रकार को बदलना चाहता हूं:

हालांकि यहाँ क्या समस्या है? आप TryFrom<ConnectParams> के लिए एक त्रुटि प्रकार का उपयोग क्यों नहीं करेंगे और दूसरा TryFrom<&'a str> के लिए?

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

क्या मानक पुस्तकालय में impl<T> From<!> for T है? मैं इसे डॉक्स में नहीं देखता, लेकिन यह सिर्फ एक रस्टडॉक बग हो सकता है। यदि यह वहां नहीं है, तो TryFrom<ConnectParams> impl के ! Error को वास्तव में मेरी आवश्यकता में बदलने का कोई तरीका नहीं है।

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

मैं कुछ और सोच रहा था जैसे कि अपने स्वयं के पूर्णांक प्रकारों को परिभाषित करने में सक्षम होना। ला. सी++:

trait IntLiteral: Integer {
    const SUFFIX: &'static str;
    const fn from_bytes(is_negative: bool, bytes: &[u8]) -> Option<Self>; // or whatever
}

impl IntLiteral for c_ulong {
    const SUFFIX: &'static str = "c_ulong";
    ...
}

extern fn foo(x: c_ulong);

foo(123c_ulong); // use a c_ulong literal
foo(123); // infer the type of the integer

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

क्या मानक पुस्तकालय में impl<T> From<!> for T है?

वर्तमान में इसलिए नहीं कि यह From<T> for T impl के विरोध में है। मेरी समझ यह है कि अंतःविषय विशेषज्ञता अंततः इसे संभालने में सक्षम होनी चाहिए।

ऐसा लगता है कि हमें कुछ वर्षों में वापस चक्कर लगाना चाहिए।

विशेषज्ञता और ! के स्थिरीकरण की समय-सीमा क्या है?

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

@canndrew मैं निश्चित रूप से सहमत हूं कि इसे हर चीज के लिए लागू नहीं किया जाना चाहिए। दस्तावेज़ कहते हैं कि _एक रूपांतरण के माध्यम से Self का निर्माण करने का प्रयास करें, लेकिन रूपांतरण के रूप में क्या मायने रखता है? एक ही चीज़ को एक प्रतिनिधित्व से दूसरे में बदलने, या रैपर जोड़ने या हटाने के बारे में क्या? इसमें आपके Vec<u8> -> String और Mutex<T> -> MutexGuard<T> के साथ-साथ u32 -> char और &str -> i64 जैसी चीज़ें शामिल हैं; SocketAddr -> TcpStream और process::Child -> process::Output को छोड़कर।

मुझे ऐसा लगता है कि impl From<T> for U का अर्थ शायद TryFrom<T, Err=!> for U $ होना चाहिए। इसके बिना, TryFrom<T> s लेने वाले फ़ंक्शन भी From<T> s नहीं ले सकते। (एक ठोस, अचूक रूपांतरण के लिए try_from() | try_into() का उपयोग करना शायद एक विरोधी पैटर्न होगा। आप इसे करने में सक्षम होंगे, लेकिन ... यह मूर्खतापूर्ण होगा, इसलिए बस ऐसा न करें ।)

मुझे लगता है कि इम्प्लांट Fromयू के लिए शायद इसका मतलब होना चाहिए TryFromतुम्हारे लिए।

माना।

आप इसे करने में सक्षम होंगे, लेकिन...यह मूर्खतापूर्ण होगा, इसलिए ऐसा न करें।

एक संभावित क्लिप्पी लिंट की तरह लगता है।

@BlacklightShining मुझे लगता है कि इसे उन प्रकारों के लिए लागू किया जाना चाहिए, जहां आउटपुट प्रकार को देखते हुए, "रूपांतरण" स्पष्ट है। जैसे ही कई रूपांतरण संभव हैं (utf8/16/32? धारावाहिक बनाम कास्टिंग? आदि ...), इसे टाला जाना चाहिए।

IMHO:

अभी, हम FromStr लागू करने वाली हर चीज़ के लिए आसानी से TryFrom<&str> का एक व्यापक कार्यान्वयन प्रदान कर सकते हैं:

impl<'a, T: FromStr> TryFrom<&'a str> for T {
    type Err = <T as FromStr>::Err;
    fn try_from(s: &'a s) -> Result<T, Self::Err> {
        T::from_str(s)
    }
}

मैं try_from स्थिर होने से पहले, या डॉक्स में इसके लिए कम से कम कुछ संदर्भ जोड़ने से पहले ऐसा कुछ देखना चाहता हूं। अन्यथा, TryFrom<&'a str> और FromStr के कार्यान्वयन में भिन्नता होना भ्रामक हो सकता है।

मैं सहमत हूं कि यह एक अच्छा समावेश होगा, लेकिन यह प्रस्तावित प्रयास -> TryFrom impl के साथ संघर्ष कर सकता है?

@sfackler संभावित रूप से। यह पूरी तरह से ठीक होगा यदि TryFrom , TryInto , और FromStr सभी एक दूसरे को डॉक्स में संदर्भित करते हैं, लेकिन मेरी मुख्य चिंता यह है कि कोई मौजूदा मानक नहीं है जो कहता है कि str::parse और str::try_into समान मान लौटाते हैं।

मैं दस्तावेज़ों में एक नरम अनुरोध के साथ ठीक हूं कि लोगों को उन्हें समान व्यवहार करने के लिए लागू करना चाहिए , हालांकि मैं निश्चित रूप से ऐसे मामले देख सकता हूं जहां कोई सोच सकता है कि वे अलग हो सकते हैं।

उदाहरण के लिए, मान लें कि कोई व्यक्ति किसी वेबसाइट के लिए Password संरचना बनाता है। वे मान सकते हैं कि "password".parse() वैधता के लिए पासवर्ड की जांच करेगा, फिर इसे हैश में बदल देगा, जबकि Password::try_from("1234abcd") यह मान सकता है कि "1234abcd" पहले से ही डेटाबेस में संग्रहीत हैश है और कोशिश करें इसे सीधे हैश में पार्स करने के लिए जिसकी तुलना की जा सकती है।

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

भले ही भाषा टीम ने अनाम पैरामीटर को हटाने के लिए RFC को बंद करने का प्रस्ताव दिया हो, लेकिन वे सभी इस बात से सहमत प्रतीत होते हैं कि आदर्श रूप से हम अनाम पैरामीटर का उपयोग करने वाला नया कोड बनाना बंद कर देंगे। इसे ध्यान में रखते हुए, क्या हम पैरामीटर नाम देने के लिए try_from / try_into के हस्ताक्षर को अपडेट कर सकते हैं? या from / into के साथ समरूपता बनाए रखना अधिक महत्वपूर्ण होगा?

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

@jimmycuadra निश्चित रूप से हाँ! कुछ पैरामीटर नाम जोड़कर एक पीआर भेजना चाहते हैं?

चीजों की वर्तमान स्थिति के संबंध में, मेरा मानना ​​​​है कि एकमात्र अनुत्तरित प्रश्न यह है कि क्या कोई होना चाहिए

impl<T, U> TryFrom<U> for T
    where T: From<U>
{
    type Error = !;

    fn try_from(u: U) -> Result<T, !> {
        Ok(T::from(u))
    }
}

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

त्रुटि टाइप करें =!;

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

@sfackler मुझे लगता है कि मैंने FromStr के बारे में बताए गए सामान में भी कारक बनाना महत्वपूर्ण होगा। क्या हमारे पास FromStr कार्यान्वयनकर्ताओं के लिए एक समान निहितार्थ होना चाहिए, या क्या उन्हें अलग होने की अनुमति दी जानी चाहिए, या क्या हमें केवल यह दस्तावेज करना चाहिए कि वे समान होने चाहिए, लेकिन होना नहीं चाहिए?

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

@jimmycuadra उस मामले में, हमें parse का उपयोग करने के लिए TryFrom को संशोधित करना चाहिए और फिर FromStr -> TryFrom के लिए एक ब्लैंकेट इम्प्लांट डालना चाहिए।

अगर हम str::parse को TryFrom के संदर्भ में लागू करने जा रहे हैं, तो क्या हमें इसी तरह ठोस प्रकारों के लिए FromStr के अन्य कार्यान्वयनों को भी बदलना चाहिए (यानी इस सूची में सभी कार्यान्वयनकर्ता : https://doc.rust-lang.org/stable/std/str/trait.FromStr.html)? क्या इसके बजाय TryFrom का उपयोग करने का सुझाव देने के लिए FromStr के दस्तावेज़ों को अद्यतन किया जाना चाहिए? क्या FromStr के मौजूदा ठोस कार्यान्वयनों को उनके दस्तावेज़ों को TryFrom संस्करण में स्थानांतरित कर दिया जाना चाहिए?

मुझे लगता है कि पश्चगामी संगतता के लिए हम FromStr नहीं बदल सकते हैं, है ना?

FromStr के पक्ष में TryFrom<&str> के पक्ष में निकालना निश्चित रूप से जंग 2.0 के लिए ध्यान में रखना कुछ है।

हां, इस सुविधा के स्थिर हो जाने पर हम एक समस्या दर्ज करेंगे और इसे 2.0-ब्रेकेज-विशलिस्ट के साथ टैग करेंगे।

एक बात पर भी विचार करना है parse_into विधि को String में जोड़ना जो TryFrom<String> का उपयोग करता है। यदि कोई प्रकार आंतरिक रूप से String स्टोर करता है, लेकिन फिर भी सत्यापन की आवश्यकता होती है, तो मैं खुद को दोनों के लिए TryFrom लागू करता हुआ पाता हूं।

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

मुझे लगता है कि समस्या यह है कि स्थिर होने के बाद उस सुविधा को स्थिर करना मुश्किल होगा और लोगों ने दोनों के लिए इम्प्लांट प्रदान किए हैं।

मुझे उम्मीद है कि पहले से ही T : From<U> होने से कार्यान्वयन उचित होने पर " स्पष्ट एपीआई छेद " श्रेणी में U : TryFrom<T> डाल दिया जाएगा।

इसका मतलब है कि कम से कम T : TryFrom<T> के साथ Error = ! होना चाहिए, लेकिन किसी भी अचूक From के लिए संस्करण स्पष्ट रूप से उससे बेहतर है।

आईएमओ वास्तव में एक स्पष्ट अंतर नहीं है कि क्या From को TryFrom कार्यान्वयन प्रदान करना चाहिए या TryFrom को From कार्यान्वयन प्रदान करना चाहिए या नहीं।

क्योंकि एक ओर, आप T::from(val) को केवल T::try_from(val).unwrap() मान सकते हैं, और दूसरी ओर, आप T::try_from(val) को केवल Ok(T::from(val)) मान सकते हैं। कौन सा बहतर है? मुझे नहीं पता।

आप T::from(val) को केवल T::try_from(val).unwrap() . मान सकते हैं

मैं उससे असहमत हूं। From कार्यान्वयन से कभी भी घबराने की उम्मीद नहीं है। केवल दूसरी तरफ समझ में आता है।

@clarcharr क्योंकि से घबराना नहीं चाहिए, विकल्प From के संदर्भ में TryFrom<Error=!> या दूसरी तरफ हैं। लेकिन मुझे सामान्य सलाह से नफरत होगी "आपको TryFrom को type Error = ! के साथ लागू करना चाहिए" के बजाय "आपको From लागू करना चाहिए"।

इसे स्थिर करने पर कुछ आंदोलन करने का कोई तरीका? 1.18 के बीटा में जाने से पहले हमारा समय समाप्त हो रहा है। @sfackler?

@rfcbot fcp मर्ज

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

• [x] @ बर्नटसुशी
• [x] @किमुंडी
• [एक्स] @ एलेक्सक्रिचटन
• [x] @ एट्यूरॉन
• [एक्स] @ ब्रोसन
• [x] @sfackler

वर्तमान में कोई चिंता सूचीबद्ध नहीं है।

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

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

@sfackler : बस चेक इन करने के लिए, क्या हम ! और कंबल इम्प्लांट्स के आसपास विभिन्न चिंताओं पर अच्छे हैं? मुझे पता है कि हमने इस बारे में libs मीटिंग में बात की थी, लेकिन यहां सारांश प्राप्त करना उपयोगी होगा।

@aturon इसके बारे में आखिरी चर्चा थी @sfackler सोच रहा था कि क्या impl From<T> for U को impl TryFrom<T> for U प्रदान करना चाहिए जहां TryFrom::Error = ! ।

@briansmith ने सुझाव दिया कि उस पर एक निर्णय एक अलग RFC हो, एक बार कभी भी प्रकार के अनसुलझे प्रश्नों पर काम नहीं किया जाता है।

क्या अब इसे स्थिर करने में मुख्य समस्या यह नहीं है कि पश्चगामी संगतता को तोड़े बिना ऐसा परिवर्तन नहीं किया जा सकता है? या उस बदलाव के साथ आगे नहीं बढ़ने का समाधान है?

मुझे लगता है कि impls का वर्तमान सेट अस्थिर है। मैं इनमें से किसी भी स्थिति को समझ सकता था:

1. TryFrom गलत रूपांतरणों के लिए अभिप्रेत है _only_, इसलिए इसमें u8 -> u128 या usize -> usize जैसी चीज़ें नहीं हैं।
2. TryFrom _all_ रूपांतरणों के लिए अभिप्रेत है, जिनमें से कुछ अचूक हैं और इस प्रकार एक निर्जन TryFrom::Error प्रकार हैं।

लेकिन अभी चीजें एक विषम संकर स्थिति में हैं जहां संकलक i32 -> i32 रूपांतरण के लिए चेकिंग कोड सम्मिलित करेगा और फिर भी आप String -> String रूपांतरण नहीं कर सकते।

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

क्या अब इसे स्थिर करने में मुख्य समस्या यह नहीं है कि पश्चगामी संगतता को तोड़े बिना ऐसा परिवर्तन नहीं किया जा सकता है? या उस बदलाव के साथ आगे नहीं बढ़ने का समाधान है?

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

यदि किसी मामले का उदाहरण है जब आप कभी भी एक अचूक रूपांतरण के लिए from $ के बजाय try_from का उपयोग करेंगे, तो मैं निश्चित रूप से अपना विचार बदल सकता हूं।

क्या आपत्ति है ! त्रुटि प्रकार के रूप में?

! स्थिरीकरण से महीनों दूर है। निकट भविष्य में TryFrom को स्थिर करने या impl<T, U> TryFrom<U> for T where T: From<U> वाले में से कोई एक चुनें।

क्या हमने यहां विशेषता उपनामों (रस्ट-लैंग/आरएफसीएस#1733) का उपयोग करने पर विचार किया है? जब वह भूमि, हम उपनाम कर सकते हैं From<T> से TryFrom<T, Error=!> , जिससे दो लक्षण एक और समान हो जाते हैं।

@lफेयरी जो $#$ From $#$ के उपयोगकर्ता impl s को तोड़ देगा, हां।

@glaebhoerl हाँ, आप सही कह रहे हैं उस RFC के प्रेरणा खंड में impl s अलियासिंग का उल्लेख है लेकिन वास्तविक प्रस्ताव उन्हें अस्वीकार करता है।

(भले ही ऐसा न हो, विधियों के अलग-अलग नाम आदि हैं)

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

सबसे पहले, आईआरसी पर इस बारे में एक अच्छी बातचीत के लिए @sfackler को धन्यवाद। चीजों को मेरे दिमाग में थोड़ी देर बैठने देने के बाद, मैं यहीं पर समाप्त हुआ।

निकट भविष्य में TryFrom को स्थिर करने या impl<T, U> TryFrom<U> for T where T: From<U> रखने में से कोई एक चुनें।

मुझे लगता है कि यहां मूल प्रश्न यह है कि क्या अचूक रूपांतरण विशेषता में हैं। मुझे लगता है कि वे आरएफसी में अचूक रूपांतरण जैसी चीजों के लिए और सामान्य उपयोग के लिए करते हैं (जैसा कि प्रतीत होता है कि बेकार कैसे है T:From<T> )। यह देखते हुए, मैं जो सबसे अधिक चाहता हूं वह एक ऐसी दुनिया से बचने के लिए है जहां हर प्रकार के कार्यान्वयनकर्ता से impl TryFrom<MyType> for MyType की अपेक्षा की जाती है, और प्रत्येक From impl का परिणाम TryFrom impl भी होना चाहिए। (या बाद में बग फाइल न करने के लिए उन्हें फाइल करवाएं।)

तो क्या हमारे पास ! को स्थिर किए बिना ब्लैंकेट इम्प्लांट हो सकता है? मुझे लगता है कि एक तरीका है, क्योंकि हमारे पास पहले से ही पुस्तकालय में ! जैसे प्रकार हैं, जैसे कि std::string::ParseError । (" यह एनम थोड़ा अजीब है: यह वास्तव में कभी मौजूद नहीं होगा। ")

यह कैसे काम कर सकता है इसका एक स्केच:

• एक नया प्रकार, core::convert::Infallible , बिल्कुल std::string::ParseError की तरह लागू किया गया। (हो सकता है कि बाद वाले को पूर्व के लिए एक प्रकार के उपनाम में भी बदल दें।)
• impl<T> From<Infallible> for T ताकि यह किसी भी त्रुटि प्रकार के साथ ? में संगत हो (बाद में c_foo सामान देखें)
• कंबल में Infallible Error प्रकार के रूप में करें
• बाद में, type Infallible = !; को नेवर टाइप को स्थिर करने के हिस्से के रूप में देखें

मैं ऐसा करने के लिए एक पीआर बनाने के लिए स्वेच्छा से काम करूंगा, अगर यह इसे ठोस बनाने में मददगार होगा।

जहां तक c_foo का सवाल है : उपरोक्त इस तरह के कोड की अनुमति देना जारी रखेगा:

fn foo(x: c_int) -> Result<i32, TryFromIntError> { Ok(x.try_into()?) }

लेकिन यह विभिन्न प्रकार की त्रुटि के कारण इस तरह के कोड को पोर्टेबिलिटी "फुटगन" बना देगा

fn foo(x: c_int) -> Result<i32, TryFromIntError> { x.try_into() }

व्यक्तिगत रूप से, मैं उस अंतर से चिंतित नहीं हूं क्योंकि जब तक c_int एक प्रकार का उपनाम है, तब तक एक "पूर्ण-ऑटो" फ़ुटगन है:

fn foo(x: c_int) -> i32 { x }

और सामान्य तौर पर, अलग-अलग इम्प्लांट्स के लिए एक विशेषता पर संबंधित प्रकार की अपेक्षा करने वाला कोड मेरे लिए एक कोड गंध की तरह लगता है। मैंने TryFrom को "सामान्यीकरण From " के रूप में पढ़ा; यदि लक्ष्य "पूर्णांक उपसमुच्चय के बीच बेहतर रूपांतरण" था - जो उपयोगी भी लगता है - तो "हमेशा एक ही त्रुटि प्रकार" तार्किक है, लेकिन मैं इसके बजाय std::num में लक्षित कुछ की अपेक्षा करता हूं, शायद num::cast::NumCast (या boost::numeric_cast )।

(इसके अलावा: #[repr(transparent)] में FCP मर्ज के साथ, शायद c_foo प्रकार नए प्रकार बन सकते हैं, जिस बिंदु पर ये रूपांतरण अधिक सुसंगत हो सकते हैं। From&TryFrom impls C "char <= short < को कूटबद्ध कर सकता है। = int <= long" नियम, साथ ही उनके लिए मानक-आवश्यक न्यूनतम आकार जैसे c_int:From<i16> या c_long:TryFrom<i64> । तब उपरोक्त रूपांतरण सभी पर i32:TryFrom<c_int> होगा प्लेटफ़ॉर्म, हमेशा समान Error प्रकार के साथ, और समस्या दूर हो जाती है।)

"यह एनम थोड़ा अजीब है: यह वास्तव में कभी मौजूद नहीं होगा।"

क्या कोई कारण है कि त्रुटि प्रकार सिर्फ इकाई नहीं हो सकता है? अद्वितीय ParseError संरचना से परेशान क्यों हैं यदि बातचीत कभी त्रुटि नहीं कर सकती है?

@sunjay () "ऐसा हो सकता है, लेकिन ऐसा होने पर आपको बताने के लिए कुछ भी दिलचस्प नहीं है" का प्रकार सिस्टम प्रतिनिधित्व है। निर्जन प्रकार (जैसे ! और std::string::ParseError ) इसके विपरीत हैं, जिस तरह से टाइप सिस्टम कहता है "यह स्थिति कभी नहीं हो सकती है, इसलिए आपको इससे निपटने की आवश्यकता नहीं है।"

@jimmycuadra

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

@scottmcm

मुझे लगता है कि यहां मूल प्रश्न यह है कि क्या अचूक रूपांतरण विशेषता में हैं।

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

let cfg = config![
    BoolOpt::SomeCfgKey => true,
    "SomeOtherCfgKey" => 77,
];

लंबी कहानी संक्षेप में, मैक्रो का विस्तार ($k, $v).into() कॉल की सूची में होता है। मैं यह सुनिश्चित करने के लिए स्ट्रिंग कुंजियों के रूपांतरण में एक जांच करना चाहता हूं कि वे एक वैध कॉन्फ़िगरेशन विकल्प का नाम दें, यानी TryFrom<(String, ???)> को लागू करना और मैक्रो को ($k, $v).try_into() का उपयोग करने के लिए बदलना। यदि सभी रूपांतरणों के लिए मैक्रो का उपयोग करने के लिए एक भी विधि नाम नहीं होता तो यह सब करना कठिन हो जाता।

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

मुझे वास्तव में यह विचार पसंद है:

impl<U: TryFrom<T, Error=!>> From<T> for U {
    fn from(val: T) -> U {
        val.unwrap()
    }
}

क्योंकि जो कोई भी TryFrom<Error=!> चाहता है वह इसे लागू कर सकता है, लेकिन लोग अभी भी From को लागू कर सकते हैं यदि वे चाहें। शायद हम अंततः From को पदावनत कर सकते हैं लेकिन हमें ऐसा करने की आवश्यकता नहीं है।

@scottmcm एक खाली एनम का उपयोग करने की योजना मुझे बहुत अच्छी लगती है।

@ Ericson2314 आपने लिखा :

यदि आप त्रुटि प्रकारों के लिए सादे From का उपयोग नहीं करते हैं (जैसे try! )! impl<T> From<!> for T उस उद्देश्य के लिए मौजूद हो सकता है और होना चाहिए।

यह व्यवहार में कैसे काम करेगा? कहो कि मैं इस तरह एक समारोह लिखने की कोशिश कर रहा हूँ:

fn myfn<P: TryInto<MyType>>(p: P) -> Result<(), MyError>

सिवाय इसके कि यह काम नहीं करता है, मुझे TryInto पर TryInto Error= निर्दिष्ट करने की आवश्यकता है। लेकिन मुझे वहां किस तरह का लिखना चाहिए? MyError स्पष्ट लगता है लेकिन फिर मैं कंबल के साथ MyType का उपयोग नहीं कर सकता TryFrom impl।

क्या आप निम्नलिखित सुझाव दे रहे हैं?

fn myfn<E: Into<MyError>, P: TryInto<MyType, Error=E>>(p: P) -> Result<(), MyError>

यह काफी वर्बोज़ लगता है।

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

शायद TryFrom परिभाषा को निम्नलिखित में बदला जाना चाहिए:

pub trait TryFrom<T, E>: Sized {
    type Error: Into<E>;

    fn try_from(t: T) -> Result<Self, E>;
}

आप त्रुटि को स्पष्ट नाम दिए बिना MyError में परिवर्तनीय होने के लिए विवश कर सकते हैं, जैसे

fn myfn<P: TryInto<MyType>>(p: P) -> Result<(), MyError> where MyError: From<P::Error>

यह अभी भी थोड़ा वर्बोज़ है, लेकिन वास्तव में फ़ंक्शन को अच्छी तरह से कॉल करने के लिए बाधाओं को बताता है (खेल का मैदान )

संपादित करें: और P::Error: Into<MyError> जैसे संस्करण के साथ प्रयास करना वास्तव में ? के साथ काम नहीं करता है क्योंकि Into के लिए Into From का कोई कंबल कार्यान्वयन नहीं है। जैसा आपने दिखाया है TryFrom को बदलना मैं उसी मुद्दे पर चलने की उम्मीद करूंगा।

अंतिम टिप्पणी अवधि अब पूरी हो गई है।

@jethrogb हे आपने मुझे एक साल पहले उद्धृत किया था इसलिए मुझे थोड़ा सोचना पड़ा। @ Nemo157 बिल्कुल सही है और यह उचित लगता है।

! के विशिष्ट मामले में हमारे पास एक ब्लैंकेट इम्प्लांट होना चाहिए , लेकिन मुझे याद है कि यह दूसरे को ओवरलैप करता है। यह एक कष्टप्रद ओवरलैप है क्योंकि दोनों कार्यान्वयन कार्यान्वयन पर सहमत हैं --- अपरिभाषित व्यवहार/मृत कोड।

एक अन्य मुद्दे से इस पर एक टिप्पणी: https://github.com/rust-lang/rust/pull/41904#issuecomment -300908910

libs टीम में से किसी के पास scottmcm के विचार पर विचार हैं? यह मेरे लिए एक महान दृष्टिकोण की तरह लगता है, और मैं एक और रिलीज चक्र को याद करने के बाद इस सुविधा को आगे बढ़ाना जारी रखना चाहता हूं।

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

इसलिए, कार्रवाई की मूल योजना impl<T, U> TryFrom<T> for U where U: From<T> को जोड़ना और अचूक पूर्णांक रूपांतरणों के लिए स्पष्ट निहितार्थों को हटाना है। एफएफआई उपयोग के मामले को संभालने के लिए हम एक अलग एपीआई बनाएंगे।

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

मैंने अभिन्न प्रकारों के लिए "अलग एपीआई" के लिए एक पीआर खोला है: https://github.com/rust-lang/rust/pull/42456

मुझे बहुत सारे रूपांतरण होने के बावजूद TryInto या TryFrom द्वारा मानकीकृत किया गया जेनेरिक कोड कभी नहीं लिखना पड़ा, इसलिए बाद वाला फॉर्म मेरे द्वारा परिभाषित प्रकारों में मेरे सभी उपयोगों के लिए पर्याप्त है। मुझे लगता है कि TryInto<...> या TryFrom<...> पैरामीटर संदिग्ध रूप की तरह लगते हैं।

एक व्युत्पन्न विशेषता के हिस्से के रूप में स्थिर होने के बाद मैं TryFrom का उपयोग करने का इरादा रखता हूं, और derive मैक्रो के हिस्से के रूप में कुछ प्रकारों पर तदर्थ आंतरिक तरीकों को कॉल करना वास्तव में अजीब होगा।

कृपया इसे न हटाएं।

मुझे कभी भी सामान्य कोड नहीं लिखना पड़ा जो कि TryInto या TryFrom . द्वारा परिचालित किया गया था

अगर ऐसा है भी, तो मुझे नहीं लगता कि यह TryInto और TryFrom बहुत कम उपयोगी बनाता है। मैं गैर-सामान्य संदर्भों में सभी जगह Into और From का उपयोग करता हूं। impl s मानक पुस्तकालय लक्षणों को जोड़ने से तदर्थ अंतर्निहित रूपांतरण विधियों के समूह की तुलना में बहुत अधिक "सामान्य" और "अपेक्षित" लगता है।

मुझे कभी भी सामान्य कोड नहीं लिखना पड़ा जो कि TryInto या TryFrom . द्वारा परिचालित किया गया था

मेरी परियोजनाओं में से एक से:

pub fn put_str_lossy<C, S> (&self, s: S)
    where C: TryInto<ascii::Char>,
          S: IntoIterator<Item = C>
{
    for c in s.into_iter() {
        self.put_char(match c.try_into() {
            Ok(c) => c,
            Err(_) => ascii::QUESTION_MARK,
        });
    }
}

क्या यह उम्मीद की जाती है कि इन लक्षणों का कार्यान्वयन किसी विशेष कानून का पालन करेगा? उदाहरण के लिए, यदि हम ए को बी और बी को ए में परिवर्तित कर सकते हैं, तो क्या यह आवश्यक है कि रूपांतरण सफल होने पर उलटा हो?:

#![feature(try_from)]

use std::convert::{TryFrom, TryInto};

fn invertible<'a, A, B, E>(a: &'a A) -> Result<(), E>
    where A: 'a + TryFrom<&'a B>,
          A: PartialEq,
          B: 'a + TryFrom<&'a A>,
          E: From<<A as TryFrom<&'a B>>::Error>,
          E: From<<B as TryFrom<&'a A>>::Error>,
{
    let b = B::try_from(a)?;
    let a2 = A::try_from(&b)?;
    assert!(a == &a2);
    Ok(())
}

संपादित करें: एस/रिफ्लेक्सिव/उलटा/

@briansmith यह देखते हुए कि From कैसे काम करता है, मैं कहूंगा कि यह इस तरह से उलटा नहीं है।

use std::collections::BinaryHeap;

fn main() {
    let a = vec![1, 2];
    let b = BinaryHeap::from(a.clone());
    let c = Vec::from(b);
    assert_ne!(a, c);
}

तो मैं इस विशेषता के वर्तमान कार्यान्वयन के बारे में सोच रहा हूं। जैसा कि #43127 में आया था (#43064 भी देखें), मुझे नहीं पता कि यह पूरी तरह से है क्योंकि कार्यान्वयन i/u128 का उपयोग करता है, लेकिन ऐसा लगता है कि कॉल TryInto इनलाइन नहीं हैं। यह बहुत इष्टतम नहीं है, और वास्तव में शून्य-लागत अमूर्तता की भावना में नहीं है। उदाहरण के लिए <u32>::try_into<u64>() का उपयोग करके अंतिम असेंबली में एक साधारण साइन विस्तार के लिए अनुकूलित करना चाहिए (बशर्ते प्लेटफॉर्म 64-बिट है), लेकिन इसके परिणामस्वरूप इसका परिणाम फ़ंक्शन कॉल होता है।

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

#42456 के अनुसार शायद हमारे पास पूर्णांक प्रकारों पर सीधे impl TryFrom नहीं होगा, लेकिन यह कैसे दिखता है कि "NumCast" विशेषता (जिसे # 43127 पर स्विच करना चाहिए) अभी भी तैयार किया जा रहा है।

भले ही वे अंत में किसी अन्य विशेषता की ओर बढ़ रहे हों, इन रूपांतरणों को आज लिबकोर में लागू किया गया है और इनका उपयोग लिबकोर में किया जा सकता है। मुझे लगता है कि सभी पूर्णांक रूपांतरणों के लिए u128 / i128 का उपयोग स्रोत कोड सादगी के लिए किया गया था। स्रोत प्रकार व्यापक है या गंतव्य की तुलना में संकरा है, इस पर निर्भर करते हुए हमें शायद इसके बजाय अलग कोड होना चाहिए। (संभवतः #[cfg(target_pointer_width = "64")] बनाम #[cfg(target_pointer_width = "32")] बनाम #[cfg(target_pointer_width = "16")] पर आधारित विभिन्न मैक्रो कॉल के साथ।)

रिमाइंडर: इसे अनवरोधित करने के लिए अधिक आवश्यकता नहीं है! यदि आप इसके लिए तैयार हैं, तो @sfackler के सारांश पर एक नज़र डालें और मार्गदर्शन के लिए मुझे या अन्य libs टीम के सदस्यों को पिंग करने के लिए स्वतंत्र महसूस करें।

मुझे नहीं पता था कि libs टीम से खरीद-फरोख्त थी कि हम @scottmcm के विचार का उपयोग धमाके के प्रकार के अस्थिर होने के लिए एक समाधान के रूप में कर सकते हैं। वर्कअराउंड का उपयोग करके उल्लिखित @sfackler परिवर्तन करने के लिए मैं पीआर पर काम कर सकता हूं।

बहुत बढ़िया, धन्यवाद @jimmycuadra!

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

अन्य साफ-सुथरे रूपांतरण हैं जो इन लक्षणों से लाभान्वित होंगे जैसे कि TryFrom<&[T]> के लिए &[T; N] । मैंने हाल ही में इसे लागू करने के लिए एक पीआर सबमिट किया है: https://github.com/rust-lang/rust/pull/44764।

TryFrom को स्थिर रखने के लिए इस तरह के रूपांतरण मेरे लिए काफी महत्वपूर्ण हैं।

#44174 विलय के साथ, मेरा मानना ​​है कि यह अब अनब्लॉक हो गया है।

उस पीआर ने किसी भी प्रकार के लिए FromStr के स्वचालित कार्यान्वयन को हटा दिया जो $#$1 TryFrom<&str> #$ को लागू करता है क्योंकि टाइप सिस्टम वर्तमान में विशेषज्ञता के साथ भी इसका समर्थन नहीं कर सकता है। आशय यह है कि इस सुविधा के स्थिर हो जाने पर FromStr और parse को TryFrom<&str> और try_into के पक्ष में हटा दिया जाए। दोनों के बीच अंतरिम अनुकूलता खोना दुर्भाग्यपूर्ण है - अगर किसी के पास स्टॉपगैप के लिए विचार हैं, तो कृपया बोलें।

अगर कोई और बदलाव नहीं किया जाना है और libs टीम में कोई स्थिरीकरण के लिए हरी रोशनी करता है, तो मैं FromStr / parse को हटाने के लिए स्थिरीकरण पीआर और पीआर कर सकता हूं।

और FromStr/parse को हटाने के लिए एक पीआर।

स्थिर पर प्रतिस्थापन उपलब्ध होने तक (या जब तक https://github.com/rust-lang/rust/issues/30785 लागू नहीं हो जाता), तब तक मूल्यह्रास चेतावनियों को नाइटली में नहीं जोड़ा जाना चाहिए, ताकि किसी भी समय एक बनाना संभव हो सके। तीनों रिलीज चैनलों पर चेतावनी के बिना क्रेट बिल्ड।

मैं अन्य पीआर से चूक गया क्योंकि संदर्भ ईमेल सूचनाओं में परिणत नहीं होते हैं। मैंने देखा कि एक विशिष्ट impl From<Infallible> for TryFromIntError है। क्या यह चर्चा के अनुसार impl<T> From<Infallible> for T नहीं होना चाहिए?

@jethrogb अफसोस की बात है कि, यह impl<T> From<T> for T के साथ संघर्ष करता है, इसलिए ऐसा नहीं किया जा सकता है (जब तक हमें चौराहे के संकेत नहीं मिलते? - और ! का उपयोग करना वहां काम नहीं करता है)।

@scottmcm आह बिल्कुल।

मुझे नहीं लगता कि आपको प्रतिच्छेदन की आवश्यकता है? क्या यह सिर्फ सीधे विशेषज्ञता नहीं है?

मैंने अन्य टिप्पणियों को नहीं पढ़ा है, लेकिन अभी मेरे लिए TryFrom टूटा हुआ है (यह पहले ठीक काम करता था)।

रस्टसी संस्करण:

rustc 1.22.0-nightly (d6d711dd8 2017-10-10)
binary: rustc
commit-hash: d6d711dd8f7ad5885294b8e1f0009a23dc1f8b1f
commit-date: 2017-10-10
host: x86_64-unknown-linux-gnu
release: 1.22.0-nightly
LLVM version: 4.0

प्रासंगिक कोड अनुभाग जिसके बारे में जंग शिकायत करता है वह यहां है: https://github.com/fschutt/printpdf/blob/master/src/types/plugins/graphics/two_Dimension/image.rs#L29 -L39 और https://github .com/fschutt/printpdf/blob/master/src/types/plugins/graphics/xobject.rs#L170 -L200 - यह कुछ हफ्ते पहले ठीक संकलित हुआ, यही कारण है कि पुस्तकालय में अभी भी "बिल्ड पासिंग" बैज है।

हालांकि, नवीनतम रात्रिकालीन निर्माण पर, TryFrom टूटता प्रतीत होता है:

error[E0119]: conflicting implementations of trait `std::convert::TryFrom<_>` for type `types::plugins::graphics::two_dimensional::image::Image`:
  --> src/types/plugins/graphics/two_dimensional/image.rs:29:1
   |
29 | / impl<T: ImageDecoder> TryFrom<T> for Image {
30 | |     type Error = image::ImageError;
31 | |     fn try_from(image: T)
32 | |     -> std::result::Result<Self, Self::Error>
...  |
38 | |     }
39 | | }
   | |_^
   |
   = note: conflicting implementation in crate `core`

error[E0119]: conflicting implementations of trait `std::convert::TryFrom<_>` for type `types::plugins::graphics::xobject::ImageXObject`:
   --> src/types/plugins/graphics/xobject.rs:170:1
    |
170 | / impl<T: image::ImageDecoder> TryFrom<T> for ImageXObject {
171 | |     type Error = image::ImageError;
172 | |     fn try_from(mut image: T)
173 | |     -> std::result::Result<Self, Self::Error>
...   |
199 | |     }
200 | | }
    | |_^
    |
    = note: conflicting implementation in crate `core`

error: aborting due to 2 previous errors

error: Could not compile `printpdf`.

तो, माना जाता है कि इसमें क्रेट core में डुप्लिकेट कार्यान्वयन है। अगर कोई इस पर गौर कर सकता है, तो यह बहुत अच्छा होगा, धन्यवाद।

@fschutt परस्पर विरोधी निहितार्थ शायद impl<T, U> TryFrom<T> for U where U: From<T> है, जिसे https://github.com/rust-lang/rust/pull/44174 में जोड़ा गया है। T मौजूद हो सकता है जैसे T: ImageDecoder और Image: From<T> दोनों।

क्या इसके लिए फीचर गेट को छोड़ने के लिए अभी भी कुछ आवश्यक है?

अगर https://github.com/rust-lang/rust/issues/35121 को पहले स्थिर किया जाता है तो हम https://github.com/rust-lang/rust/pull/ में पेश किए गए Infallible प्रकार को हटा सकते हैं। 44174 और इसके बजाय ! का उपयोग करें। मुझे नहीं पता कि क्या इसे एक आवश्यकता माना जाता है।

मुझे लगता है कि यहां मुख्य अवरोधक अभी भी पूर्णांक प्रकार है। या तो हम पूर्णांक प्रकारों के लिए एक अलग Cast विशेषता का उपयोग करते हैं https://github.com/rust-lang/rust/pull/42456#issuecomment -326159595, या पोर्टेबिलिटी लिंट #41619 को पहले करें।

इसलिए मेरे पास एक एनम हुआ करता था जो TryFrom के लिए AsRef<str> लागू करता था, लेकिन यह कुछ महीने पहले टूट गया। मैंने सोचा था कि यह रात में पेश किया गया एक बग था जो समय के साथ दूर हो जाएगा, लेकिन ऐसा प्रतीत होता है कि ऐसा नहीं है। क्या यह अब TryFrom के लिए समर्थित पैटर्न नहीं है?

impl<S: AsRef<str>> TryFrom<S> for MyEnum {
    type Error = &'static str;

    fn try_from(string: S) -> Result<Self, Self::Error> {
        // Impl here
    }
}
...

&str और String दोनों से कनवर्ट करने के लिए अन्य विकल्प क्या हैं?

@kybishop MyEnum लागू करता है FromStr ? यह आपके टूटने का स्रोत हो सकता है।

@nvzqz ऐसा नहीं है, हालांकि मुझे जंग आईआरसी के माध्यम से TryFrom का उपयोग करने की अनुशंसा की गई थी क्योंकि यह एक अधिक सामान्यीकृत समाधान है। TryFrom ने शुरुआत में बहुत अच्छा काम किया जब तक कि कुछ महीने पहले रात में w/e ब्रेकिंग परिवर्तन नहीं हुआ।

संपादित करें: क्या आपका मतलब है कि मुझे FromStr को लागू करने के लिए स्विच करना चाहिए, या यदि यह _did_ impl FromStr है, तो इससे टूट-फूट हो सकती है?

संपादित करें 2: यहां उन जिज्ञासु लोगों के लिए पूर्ण, बल्कि संक्षिप्त और सरल है: https://gist.github.com/kybishop/2fa9e9d32728167bed5b1bc0b9becd97

@kybishop क्या कोई विशेष कारण है कि आप $#$ &str $#$ के बजाय AsRef<str> के लिए कार्यान्वयन चाहते हैं?

@sfackler मैं इस धारणा के तहत था कि यह &str और String दोनों से रूपांतरण की अनुमति देता है, हालांकि मैं अभी भी एक जंग नौसिखिया हूं, इसलिए शायद मैं गलत समझ रहा हूं कि कैसे AsRef<str> का उपयोग किया जाता है। मैं &str से दूर जाने की कोशिश करूंगा और देखूंगा कि क्या AsRef कुछ &str की अनुमति दे रहा था।

@kybishop https://github.com/rust-lang/rust/issues/33417#issuecomment -335815206 के समान है, और जैसा कि कंपाइलर त्रुटि संदेश कहता है, यह impl<T, U> std::convert::TryFrom<U> for T where T: std::convert::From<U> impl के साथ एक वास्तविक संघर्ष है जो था libcore में जोड़ा गया।

एक प्रकार T (संभवतः डाउनस्ट्रीम क्रेट में) हो सकता है जो दोनों को लागू करता हैFrom<MyEnum> और AsRef<str>और MyEnum: From<T> है . उस स्थिति में, दोनों निहितार्थ लागू होंगे, इसलिए दोनों निहितार्थों को एक साथ मौजूद रहने की अनुमति नहीं है।

@SimonSapin समझ गया। तो &str और &String दोनों से रूपांतरित होने के इच्छुक लोगों के लिए क्या विकल्प हैं? बस दोनों के लिए TryFrom लगाना है?

संपादित करें: मुझे लगता है कि मैं सिर्फ अतिरिक्त काम खा सकता हूं और .as_ref() पर String s पर कॉल कर सकता हूं। फिर मेरे पास $ str के लिए केवल एक TryFrom impl हो सकता है।

हां, दो इम्प्लांट्स (संभवतः एक दूसरे के आधार पर, जैसा कि आपने बताया) तब तक काम करना चाहिए जब तक MyEnum From<&str> या From<String> को लागू नहीं करता है।

@kybishop String लागू करता है Deref<str> , इसलिए टाइप अनुमान को &String को TryFrom impl में पास करते समय &str में जबरदस्ती करने की अनुमति देनी चाहिए। as_ref पर कॉल करने की हमेशा आवश्यकता नहीं हो सकती है।

अगर कोई इसका त्वरित उदाहरण ढूंढ रहा है: https://play.rust-lang.org/?gist=bfc3de0696cbee0ed9640a3f60b33f5b&version=nightly

! को स्थिर करने के लिए https://github.com/rust-lang/rust/pull/47630 के साथ, क्या पीआर के लिए Infallible को ! से बदलने की भूख है ?

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

type Infallible = !;

बस अंदर कूद रहा हूं। मैं उस पर @scottmcm के साथ हूं।

हालांकि, यह अतिरिक्त ओवरहेड जोड़ता है कि यह सुविधा ( TryInto / TryFrom ) अब एक अन्य अस्थिर सुविधा पर निर्भर करती है - never_type ।

साथ ही, Infallible का यह फायदा है कि यह इस बारे में अधिक जानकारी / अर्थ देता है कि इस प्रकार का निर्माण क्यों नहीं किया जा सकता है। मैं अभी अपने आप से राय रखता हूं।

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

@jdahlstrom मैं पूरी तरह से सहमत हूँ। हमें इसे रस्ट बुक या नोमिकॉन में पेश करना होगा ताकि यह "जमीनी सच्चाई" और मैत्रीपूर्ण हो।

इस API के लिए RFC को सबमिट किए हुए अब दो साल हो चुके हैं।

~ @ ब्रायनस्मिथ : एक स्थिरीकरण पीआर प्रगति पर है। ~

संपादित करें : या शायद मैं बहुत थक गया हूँ ...

आपने ! प्रकार के स्थिरीकरण के पीआर को लिंक किया है।

चूंकि ! स्थिरीकरण पीआर अभी विलय हुआ है, इसलिए मैंने convert::Infallible को ! से बदलने के लिए एक पीआर सबमिट किया है: #49038

https://github.com/rust-lang/rust/pull/49038 मर्ज हो गया है। मेरा मानना ​​है कि यह स्थिरीकरण के लिए आखिरी अवरोधक था, कृपया मुझे बताएं कि क्या मैं एक अनसुलझे मुद्दे से चूक गया हूं।

@rfcbot fcp मर्ज

rfcbot प्रतिसाद नहीं दे रहा है क्योंकि एक और FCP पहले ही https://github.com/rust-lang/rust/issues/33417#issuecomment -302817297 पर पूरा हो चुका है।

उम्म, कुछ निहितार्थ हैं जिन पर दोबारा गौर किया जाना चाहिए। अब जब हमारे पास impl<T, U> TryFrom<U> for T where T: From<U> के शेष इम्प्लांट्स जिनमें TryFrom type Error = ! हैं, उन्हें या तो From के इम्प्लांट्स से बदल दिया जाना चाहिए, हटा दिया जाना चाहिए, या गलत बनाया जाना चाहिए ( त्रुटि प्रकार को कुछ गैर-निर्वासित प्रकार में बदलना)।

उस मामले में जो मुझे मिल सकते हैं उनमें usize या isize शामिल हैं। मुझे लगता है कि संबंधित From impls मौजूद नहीं हैं क्योंकि उनकी गिरावट लक्ष्य सूचक आकार पर निर्भर करती है। वास्तव में TryFrom इम्प्लांट अलग-अलग लक्ष्यों के लिए अलग-अलग उत्पन्न होते हैं: https://github.com/rust-lang/rust/blob/1.24.1/src/libcore/num/mod.rs#L3103 -L3179 ​​यह शायद एक पोर्टेबिलिटी खतरा है।

अलग-अलग लक्ष्यों के लिए अलग-अलग जेनरेट किया गया

स्पष्ट करने के लिए: एक ही impl में अलग-अलग target_pointer_width के लिए अलग-अलग विधि निकाय ठीक हैं (और संभावित रूप से आवश्यक), अलग-अलग एपीआई (त्रुटि प्रकार) नहीं हैं।

स्थिरीकरण पीआर: #49305। वहां कुछ चर्चा के बाद, यह पीआर कुछ TryFrom इम्प्लांट्स को भी हटा देता है जिसमें usize या isize शामिल हैं क्योंकि हमने उन्हें लागू करने के दो अलग-अलग तरीकों के बीच फैसला नहीं किया है। (और हम निश्चित रूप से केवल एक ही हो सकते हैं।)

उनके लिए समर्पित ट्रैकिंग समस्या: https://github.com/rust-lang/rust/issues/49415

TryFrom ने बिना किसी फीचर गेटिंग के rustc 1.27.0-nightly (ac3c2288f 2018-04-18) पर पूरी तरह से काम किया लेकिन rustc 1.27.0-nightly (66363b288 2018-04-28) के साथ संकलित होने पर टूट गया।

क्या पिछले 10 दिनों में इस सुविधा के स्थिरीकरण में कोई कमी आई है?

@kjetilkjeka इस सुविधा को हाल ही में अस्थिर किया गया है: #50121।

(स्थिरीकरण पूर्ववत किए जाने के बाद से फिर से खोलना)

@kjetilkjeka TryFrom के स्थिरीकरण को https://github.com/rust-lang/rust/pull/50121 में ! प्रकार के स्थिरीकरण के साथ वापस कर दिया गया है, क्योंकि TryFrom<U, Error=!> for T where T: From<U> ! प्रकार https://github.com/rust-lang/rust/issues/49593 के कारण अस्थिर था।

समझाने के लिए धन्यवाद। क्या इसका मतलब यह है कि यह सुविधा अनिवार्य रूप से संकलक प्रकार के ज़बरदस्ती में कुछ बदलावों पर अवरुद्ध है? मुझे यह बताते हुए कोई समस्या नहीं मिल रही है कि किन परिवर्तनों की आवश्यकता है, क्या इस बिंदु पर ज्ञात परिवर्तनों की परिमाण है?

क्या कोई मौलिक कारण है कि हम आगे नहीं बढ़ सके और TryFrom विशेषता को स्थिर नहीं कर सके, और कोई भी अर्थ जिसमें ! शामिल नहीं है, और केवल ! से जुड़े स्थिरीकरण को स्थगित करें ! के संभावित स्थिरीकरण के बाद तक?

https://github.com/rust-lang/rust/pull/49305#issuecomment -376293243 विभिन्न संभावित विशेषता कार्यान्वयनों को वर्गीकृत करता है।

@joshtriplett जहां तक ​​​​मैं समझता हूं, विशेष रूप से impl<T, U> TryFrom<T> for U where U: From<T> { type Err = !; } पिछड़ा-संगत नहीं है यदि TryFrom पहले से ही स्थिर है।

@SimonSapin
वह जोड़ने के लिए पिछड़ा-संगत क्यों नहीं है?

(और क्या हमें वास्तव में कंबल की जरूरत है?)

वह जोड़ने के लिए पिछड़ा-संगत क्यों नहीं है?

मुझे लगता है कि यह पिछड़ा संगत नहीं है क्योंकि TryFrom को मैन्युअल रूप से TryFrom के बीच स्थिर किया जा सकता था और ! को स्थिर किया गया था। जब कंबल कार्यान्वयन जोड़ा गया था तो यह मैन्युअल कार्यान्वयन के साथ विरोधाभासी होगा।

(और क्या हमें वास्तव में कंबल की जरूरत है?)

मुझे लगता है कि TryFrom से अधिक जेनेरिक कोड लिखते समय कंबल का अर्थ वास्तव में समझ में आता है। T में रूपांतरण की संभावना वाले सभी प्रकारों का जिक्र करते समय आप अधिकतर उन सभी प्रकारों को भी शामिल करना चाहेंगे जिन्हें निश्चित रूप से T में परिवर्तित किया जा सकता है। मुझे लगता है कि एक विकल्प यह हो सकता है कि सभी को TryFrom को लागू करने वाले सभी प्रकारों के लिए From लागू करने की आवश्यकता हो और कंबल इम्प्लांट बनाने से पहले विशेषज्ञता की प्रतीक्षा करें। आपको अभी भी समस्या होगी कि Err को Result जेनेरिक ओवर बनाने के लिए क्या किया जाए। ! रूपांतरण की अचूकता को व्यक्त करने और प्रोग्रामिक रूप से लागू करने के लिए एक अच्छा तरीका लगता है, और उम्मीद है कि प्रतीक्षा के लायक है।

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

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

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

जब भी इसे स्थिर किया जाता है: _कृपया_ प्रस्तावना में TryFrom और TryInto जोड़ें।

@SergioBenitez हमने कुछ समय के लिए नाइटली पर ऐसा किया है, और दुर्भाग्य से यह क्रेट के लिए एक ब्रेकिंग परिवर्तन था जो उनके अपने TryFrom या TryInto विशेषता को परिभाषित करता है ( std के उपयोग के लिए)

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

TryFrom और TryInto के लिए हालांकि, 2018 संस्करण के लिए एक अलग प्रस्तावना एक समाधान होगा। इस पर पहले भी अनौपचारिक रूप से चर्चा की जा चुकी है लेकिन मुझे यह फाइल नहीं मिली, इसलिए मैंने https://github.com/rust-lang/rust/issues/51418 खोला।

इसी तरह की समस्या का एक सामान्य समाधान विस्तार के लिए लागू किया गया था
https://github.com/rust-lang/rust/issues/48919 में विधियां, जिससे अस्थिर
जब स्थिर कोड टकराता है तो एक्सटेंशन विधियां चेतावनियां जारी करती हैं।

ऐसा लगता है कि आप इसमें जोड़े गए नए शब्दों के साथ कुछ ऐसा ही कर सकते हैं
प्रस्तावना?

गुरु, जून 7, 2018, 11:47 AM पर साइमन सैपिन सूचनाएं @github.com ने लिखा:

@SergioBenitez https://github.com/SergioBenitez हमने वह किया है
रात में थोड़ी देर के लिए, और दुर्भाग्य से यह बक्से के लिए एक ब्रेकिंग बदलाव था
जो अपने स्वयं के TryFrom या TryInto विशेषता को परिभाषित करते हैं (उपयोग के लिए जबकि std
वाले अस्थिर हैं), पर्याप्त है कि हमने इसे वापस कर दिया है।

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

हालांकि, TryFrom और TryInto के लिए, एक समाधान अलग होना चाहिए
2018 संस्करण के लिए प्रस्तावना। इस पर पहले अनौपचारिक रूप से चर्चा की गई है लेकिन
मुझे यह दर्ज नहीं मिला, इसलिए मैंने #51418 खोला
https://github.com/rust-lang/rust/issues/51418 ।

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

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

@SimonSapin TryFrom/TryInto स्थिरीकरण के लिए वर्तमान योजना क्या है? मुझे 29 अप्रैल को इसे वापस किए जाने के अलावा कुछ भी ठोस नहीं मिला।

@nayato यह कभी भी टाइप नहीं करने वाले https://github.com/rust-lang/rust/issues/35121 को स्थिर (फिर से) करने पर अवरुद्ध है, जो स्वयं https://github.com/rust-lang/rust/ पर अवरुद्ध है।

@SimonSapin नेवर टाइप का इस्तेमाल केवल यहां किया जाता है। क्या हम उस कार्यान्वयन के बिना TryFrom को स्थिर कर सकते हैं और जब कभी स्थिर नहीं होते हैं तो इसे जमीन पर उतार सकते हैं? TryFrom Try बहुत ही महत्वपूर्ण इंटरफ़ेस है।

दुर्भाग्य से नहीं। विशेषता के स्थिर हो जाने के बाद इस ब्लैंकेट इम्प्लांट को जोड़ना एक महत्वपूर्ण बदलाव होगा और उदाहरण के लिए, उदाहरण के लिए, क्रेट्स.io पुस्तकालयों को TryFrom<Foo> for Bar लागू करने का मौका मिला है, जबकि उनके पास From<Foo> for Bar भी है, जैसा कि इम्प्लस के रूप में है। ओवरलैप होगा।

अब तक का निर्णय यह रहा है कि TryFrom को From के साथ इस तरह से "संगत" बनाना स्थिरीकरण को अवरुद्ध करने के लिए काफी महत्वपूर्ण था।

शायद भोला और मूर्खतापूर्ण विचार:

क्या होगा अगर rustc को इस बीच एक हमेशा चालू त्रुटि लिंट मिल गया जो Error<_, !> के लिए ट्रिगर हुआ, उपयोगकर्तालैंड में किसी भी निहितार्थ को रोकने, बाद में impl s को जोड़ने की अनुमति देता है?

या किसी प्रकार की त्रुटि के साथ अस्थिर impl<T: From<U>, U> TryFrom<U> for T । क्या विशेषता निहितार्थ अस्थिर हो सकते हैं?

@जेथ्रोगब नहीं

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

इस निहितार्थ के कारण इसे अवरुद्ध किया गया है:

impl<T, U> TryFrom<U> for T where T: From<U> {
    type Error = !;

    fn try_from(value: U) -> Result<Self, Self::Error> {
        Ok(T::from(value))
    }
}

@rust-lang/libs अनब्लॉक करने के लिए, कभी भी टाइप न करने के बजाय enum Infallible {} पर वापस जाने के बारे में आप क्या सोचते हैं?

मुझे व्यक्तिगत रूप से enum Infalliable {} होने और फिर बाद में इसे type Infalliable = ! में बदलने से कोई फर्क नहीं पड़ता।

हमने कल की लिब्स ट्राइएज मीटिंग में इस पर चर्चा की, लेकिन यह याद नहीं कर सका कि क्या स्थिरीकरण के बाद ऐसा परिवर्तन ठीक होगा या यदि हमने संभावित टूटने के कारण उस विचार को पहले ही खारिज कर दिया था, या वह टूटना क्या होगा।

हमने जो याद किया वह यह है कि हमें केवल एक ऐसा प्रतिस्थापन करने को मिलता है: यदि दो अयस्क अधिक स्थिर मानक पुस्तकालय खाली एनम (अलग प्रकार) बाद में एक ही प्रकार के हो जाते हैं, तो एक टोकरा जिसमें दोनों के लिए कुछ impl s होता है, टूट जाएगा जैसे-जैसे निहितार्थ अतिव्यापी (या समान) हो जाते हैं। उदाहरण के लिए impl From<std::convert::Invallible> for MyError और impl From<std::string::ParseError> for MyError ।

वैसे, हमारे पास std::string::ParseError है, जहां तक ​​​​मैं बता सकता हूं कि 1.30.0 मानक पुस्तकालय में एकमात्र खाली एनम है। इसलिए यदि हम आश्वस्त हो सकते हैं कि इस योजना के साथ कोई अन्य समस्या नहीं है, तो हम यह कर सकते हैं:

• string::ParseError को convert::Infallible . पर ले जाएं
• इसे अपने पुराने स्थान पर pub use या pub type के साथ पुनः निर्यात करें (क्या इससे कोई फर्क पड़ता है?)
• इसे TryFrom ब्लैंकेट इम्प्लांट में इस्तेमाल करें
• बाद में, उसी रिलीज में जब कभी भी प्रकार स्थिर नहीं होता है, तो string::ParseError और convert::Infallible दोनों को $#$ type _ = ! $#$ से बदलें और ! सीधे उपयोग करें जहां उनका उपयोग किया गया था।
• (वैकल्पिक) बाद में, पुराने उपनामों के लिए बहिष्करण चेतावनियां जारी करें

बस और अनिच्छा से मेरे अपने टोकरे में एक TryFrom प्लेसहोल्डर विशेषता जोड़ने के बाद, और निश्चित रूप से RFC और स्थिरीकरण प्रयासों के निहितार्थों को पूरी तरह से समझे बिना, मुझे आश्चर्य है कि From के लिए एक कंबल TryFrom From Infallible / ! त्रुटि प्रकार के साथ यह क्या रोक रहा है? स्थिर एसटीडी TryFrom और कंबल TryInto लक्षण स्थापित करने के बाद क्या ये द्वितीयक लक्ष्य नहीं हैं? मेरा मतलब है, यहां तक ​​​​कि From से TryFrom (जिसका उद्देश्य मुझे पूरी तरह से समझ में नहीं आता) के उत्थान की कमी है, क्या यह कम मंथन नहीं होगा यदि हर टोकरा जिसे इसकी आवश्यकता है वह नहीं जोड़ता है इसका अपना TryFrom ?

स्पष्ट समस्या अगर TryFrom को कंबल के बिना From के लिए भेज दिया जाता है, तो यह है कि क्रेट एक ही प्रकार के लिए TryFrom और From को लागू कर सकते हैं (संभवतः ठीक इसलिए कि कंबल इम्प्लांट नहीं है), और जब कंबल इंप को libstd में जोड़ा जाता है तो वे टूट जाते हैं।

हालाँकि, इसके बारे में सोचें, शायद यह विशेषज्ञता के साथ एक ब्रेकिंग बदलाव नहीं होगा?

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

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

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

https://github.com/rust-lang/rust/issues/33417#issuecomment -423073898 में उल्लिखित योजना के शुरू होने के लिए क्या आवश्यक है? मदद के लिए क्या किया जा सकता है?

यह एक धन्यवादहीन कार्य है, लेकिन यह मदद करेगा यदि कोई इस ट्रैकिंग समस्या के माध्यम से जा सकता है और https://github.com/rust-lang/rust/issues/35121 यह जांचने के लिए कि क्या उस योजना में कोई समस्या है कि हम ' मैंने पहले चर्चा की थी और भूल गए थे, विशेष रूप से enum Infallible को type Infallible = !; के साथ बदलने के बाद पिछले रिलीज में एनम स्थिर होने के बाद एक ब्रेकिंग बदलाव हो सकता है।

क्या विशेषता के साथ Infallible एनम को स्थिर करने की आवश्यकता है? यदि इसे अस्थिर रखा जाता है, तो कोई भी इसका नाम नहीं ले सकता है, और इसलिए इसे बाद में ! के लिए स्वैप करना ठीक होना चाहिए?

@seanmonstar नहीं, आप इसे <u16 as TryFrom<u8>>::Error का उपयोग करके संदर्भित कर सकते हैं और इसे एक स्थिर नाम माना जाता है। साक्षी:

// src/lib.rs
#![feature(staged_api)]
#![stable(since = "1.0.0", feature = "a")]

#[stable(since = "1.0.0", feature = "a")]
pub trait T1 {
    #[stable(since = "1.0.0", feature = "a")]
    type A;
}

#[unstable(issue = "12345", feature = "b")]
pub struct E;

#[stable(since = "1.0.0", feature = "a")]
impl T1 for u8 {
    type A = E;
}

// src/bin/b.rs
extern crate a;

trait T3 {}

impl T3 for <u8 as a::T1>::A {}
impl T3 for a::E {}

fn main() {}

पहला T3 impl कोई त्रुटि उत्पन्न नहीं करता है। केवल दूसरा T3 impl E0658 "अस्थिर पुस्तकालय सुविधा का उपयोग" त्रुटि का कारण बनता है।

यानी.... वाह, बस काटने के लिए कह रहा हूँ >_<

मैं व्यक्तिगत रूप से अज्ञात प्रकारों को वापस करने के लिए एक गैर-निर्यात मॉड्यूल में एक प्रकार को सार्वजनिक करने की चाल का उपयोग करता हूं, और जब कोई ऐसा करता है जो आपने कहा है तो इसका मतलब टूटना होगा यदि उन्होंने ऐसा किया, तो मेरी भावनाएं "उन पर शर्म आती हैं", और इस पर विचार न करें अज्ञात प्रकार को तोड़ने के रूप में समायोजित करना।

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

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

उदाहरण के लिए, String::from_utf8 के साथ, हम देख सकते हैं कि त्रुटि प्रकार में स्वामित्व इनपुट Vec<u8> है ताकि इसे वापस देने में सक्षम हो :

// some invalid bytes, in a vector
let sparkle_heart = vec![0, 159, 146, 150];

match String::from_utf8(sparkle_heart) {
    Ok(string) => {
        // owned String binding in this scope
        let _: String = string;
    },
    Err(err) => {
        let vec: Vec<u8> = err.into_bytes(); // we got the owned vec back !
        assert_eq!(vec, vec![0, 159, 146, 150]);
    },
};

इसलिए, अगर हमें String: TryFrom<Vec<u8>> का कार्यान्वयन प्राप्त करना था, तो यह उम्मीद की जाएगी कि <String as TryFrom<Vec<u8>>>::Error FromUtf8Error सही होगा?

हां, त्रुटि प्रकार में इनपुट मान "बैक" देना एक वैध विकल्प है। impl<'a> TryFrom<&'a Foo> for Bar के साथ एक संदर्भ लेना एक और बात है।

इस विशिष्ट उदाहरण में हालांकि मुझे यकीन नहीं है कि TryFrom impl उपयुक्त है। यूटीएफ -8 यूनिकोड में बाइट्स के संभावित डिकोडिंग में से केवल एक है, और from_utf8 इसके नाम पर दर्शाता है।

यह एक धन्यवादहीन कार्य है, लेकिन यह मदद करेगा यदि कोई इस ट्रैकिंग समस्या से गुजर सकता है और #35121 यह जांचने के लिए कि क्या उस योजना में कोई समस्या है जिसके बारे में हमने पहले चर्चा की है और भूल गए हैं, विशेष रूप से enum Infallible की जगह ले रहे हैं या नहीं पिछले रिलीज में एनम स्थिर होने के बाद # type Infallible = !; के साथ एक ब्रेकिंग बदलाव हो सकता है।

इस मुद्दे या #35121 में इसके साथ कोई ठोस समस्या नहीं बताई गई थी। ! के विशेष होने की संभावना के बारे में एक चिंता थी कि किसी तरह से निर्जन प्रकार नहीं हैं। लेकिन पीआर में कोई चिंता नहीं है और कोड समीक्षा टिप्पणियों से यह स्पष्ट है कि एनम स्थिर होना एक संभावना थी (हालांकि ऐसा कभी नहीं हुआ)। मैंने जो पाया उसके लिंक यहां दिए गए हैं।

मूल अवधारणा
एक सार चिंता
lib टीम से आगे बढ़ें

के बाद:

44174 सितम्बर 29: अचूक प्रकार जोड़ा गया

47630 मार्च 14: नेवर टाइप को स्थिर करें!

49038 मार्च 22: अचूक को नेवर टाइप में परिवर्तित किया!

49305 मार्च 27: ट्राईफ्रॉम को स्थिर किया गया

49518 मार्च 30: प्रस्तावना से हटाया गया

50121 अप्रैल 21: अस्थिर

जब ! स्थिर हो जाए,

क्या यह काम करेगा?

impl<T, U> TryFrom<U> for T
where U: Into<T> {
    type Err = !;

    fn try_from(u: U) -> Result<Self, !> { Ok(u.into()) }
}

impl<T, U> TryInto<U> for T
where U: TryFrom<T> {
    type Err = U::Err;

    fn try_into(self) -> Result<U, !> { U::try_from(self) }
}

इस तरह सभी अचूक रूपांतरण ( From और Into के साथ) को एक समान TryFrom और TryInto प्राप्त होता है जहां Err ! है TryFrom impl के लिए एक TryInto impl प्राप्त होता है जैसे कि हम प्रत्येक From impl के लिए Into impl कैसे प्राप्त करते हैं।

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

फिर हम impl TryFrom<T, Err = !> impl TryInto<T, Err = !> impl From<T> impl Into<T> करने के संकेत के साथ लिंट कर सकते हैं।

हमारे पास पहले से ही ये दोनों निहितार्थ हैं:

https://doc.rust-lang.org/1.31.0/std/convert/trait.TryFrom.html#impl -TryFrom%3CU%3E
https://doc.rust-lang.org/1.31.0/std/convert/trait.TryInto.html#impl -TryInto%3CU%3E

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

impl<T, U> TryFrom<U> for T where    T: From<U>,

प्रति

impl<T, U> TryFrom<U> for T where    U: Into<T>,

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

क्या आप इसे आज़माना चाहेंगे, देखें कि क्या यह संकलित करता है, और एक पुल अनुरोध भेजें?

हाँ मैं कोशिश करना चाहूंगा।

क्या ऐसा कोई मामला है जहां From<U> for T लागू नहीं किया जा सकता है, लेकिन Into<T> for U और TryFrom<U> for T हो सकता है?

हाँ, उदाहरण के लिए

use other_crate::OtherType;

struct MyType;

// this impl will fail to compile
impl From<MyType> for OtherType {
    fn from(my_type: MyType) -> OtherType {
        // impl details that don't matter
    }
}

// this impl will not fail to compile
impl Into<OtherType> for MyType {
    fn into(self) -> OtherType {
        // impl details that don't matter
    }
}

यह अनाथ नियमों के कारण है।
TryFrom और From अनाथ नियमों के संदर्भ में समान हैं, और इसी तरह TryInto और Into अनाथ नियमों के संदर्भ में समान हैं

@KrishnaSannasi आपका उदाहरण संकलित करेगा, बस इस खेल के मैदान का उदाहरण देखें

मुझे लगता है कि सबसे अद्यतन सुसंगतता नियम इस आरएफसी में वर्णित है और दोनों कार्यान्वयन की अनुमति दी जानी चाहिए।

struct MyType<T>(T);

impl<T> From<MyType<T>> for (T,) {
    fn from(my_type: MyType<T>) -> Self {
        unimplemented!()
    }
}

impl<T> Into<(T,)> for MyType<T> {
    fn into(self) -> (T,) {
        unimplemented!()
    }
}

खेल का मैदान
आह हाँ, लेकिन जैसे ही आप सामान्य पैरामीटर जोड़ते हैं, यह खत्म हो जाता है। यदि आप प्रत्येक इंप को व्यक्तिगत रूप से संकलित करने का प्रयास करते हैं और संकलित करते हैं तो From एक संकलित करने में विफल हो जाएगा, जबकि Into एक संकलित होगा।

एक और कारण है कि मैं यह परिवर्तन चाहता हूं क्योंकि वर्तमान में, यदि आप Into impl लिखते हैं, तो आप नहीं करते हैं, और स्वचालित रूप से TryInto impl प्राप्त नहीं कर सकते हैं। मैं इसे एक खराब डिज़ाइन के रूप में देखता हूं क्योंकि यह From और TryFrom के साथ असंगत है।

मैं और अधिक पूछ रहा हूं कि क्या कभी ऐसा कोई मामला है जहां आप TryFrom<U> for T को Into<T> for U से ऑटो-व्युत्पन्न करना चाहते हैं, लेकिन जहां From<U> for T लागू नहीं किया जा सकता है। यह मुझे बेमानी लगता है।

मैं निश्चित रूप से Into से TryInto ब्लैंकेट इम्प्लांट चाहता हूं, लेकिन दुर्भाग्य से टाइप सिस्टम वर्तमान में इस तरह के ब्लैंकेट इम्प्लांट की अनुमति नहीं देता है क्योंकि यह अन्य From से TryFrom के साथ संघर्ष करता है From से Into कंबल निहितार्थ (या, कम से कम, यह मेरी समझ है)।

मुझे पूरा यकीन है कि ये उपयोग के मामले ठीक वही थे जो RFC @kjetilkjeka से जुड़े थे जिन्हें ठीक करना था। इसके लागू होने के बाद ऐसा कोई मामला नहीं होना चाहिए जहां आप Into लागू कर सकें लेकिन From नहीं।

@scottjmaddox मैं जरूरी नहीं चाहता कि Into का अर्थ TryFrom हो जितना मैं Into का अर्थ TryInto के लिए चाहता हूं। इसके अलावा From और Into शब्दार्थ रूप से समकक्ष हैं, सिर्फ इसलिए कि हम यह व्यक्त नहीं कर सकते कि हमारे विशेषता प्रणाली में इसका मतलब यह नहीं है

TryFrom<U> for T को Into<T> for U से ऑटो-व्युत्पन्न किया जाना है, लेकिन where From<U> for T को लागू नहीं किया जा सकता है।

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

@clarcharr भले ही ऐसा हो, फिर भी Into दोनों का मतलब TryInto और TryFrom TryInto दोनों को दो कंबल के रूप में रखने का कोई तरीका नहीं है। निहितार्थ संघर्ष करेंगे। मैं चाहता हूं कि Into का अर्थ TryInto हो, और TryFrom का अर्थ TryInto हो। जिस तरह से मैं प्रस्ताव करता हूं, वह अप्रत्यक्ष रूप से ही होगा।

मैंने अपने पुल अनुरोध पर एक टिप्पणी की, जहां मैंने इस बदलाव के लिए अपने प्रमुख कारण यहां दिए हैं

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

स्पष्ट होने के लिए, मुझे ये चार अर्थ चाहिए

• From का अर्थ है Into (स्थिरता के लिए)
• TryFrom का अर्थ है TryInto या TryInto का अर्थ है TryFrom (क्योंकि वे शब्दार्थ समकक्ष हैं)
• From का अर्थ है TryFrom
• Into का अर्थ है TryInto

मुझे परवाह नहीं है कि वे प्रत्यक्ष या अप्रत्यक्ष रूप से किए जाते हैं।

या, हम TryInto एक उपनाम बना सकते हैं:

trait TryInto<T> = where T: TryFrom<Self>;

मुझे नहीं पता कि यह वास्तव में काम करेगा या नहीं, लेकिन यह काफी आसान लगता है।

into पद्धति को कहाँ परिभाषित किया जाएगा?

@clarcharr @SimonSapin की तरह कहा, विधि में कहां परिभाषित किया जाएगा। हमारे पास विशेषता उपनाम नहीं हैं। इसके लिए एक और RFC होना चाहिए। और हमें इसे उस RFC पर ब्लॉक करना होगा, जो अवांछनीय है।

@KrishnaSannasi वर्तमान में From => Into , From => TryFrom , TryFrom => TryInto , और Into => TryInto के सभी चार होना असंभव है, क्योंकि From को लागू करने वाली हर चीज TryInto (एक From => Into => TryInto , और दूसरा From => TryFrom => TryInto ) के लिए दो प्रतिस्पर्धी इम्प्लांट हैं।

चूंकि From => Into और TryFrom => TryInto दोनों ही महत्वपूर्ण हैं, Into => TryInto का त्याग करना होगा। या कम से कम मेरी समझ तो यही है।

हाँ, मुझे नहीं लगा कि TryInto उपनाम ठीक से निकल गया है, इसलिए मुझे अनदेखा करें> <

हालांकि मैं @scottjmadox जो कहता हूं उससे सहमत हूं।

@scottjmadox

बस एक संभावित गलतफहमी को दूर करने के लिए, मैं From ऑटो इम्प्लांट्स TryFrom को हटा रहा हूं और इसे Into ऑटो इम्प्लस TryFrom से बदल रहा हूं।

वर्तमान में सभी चार से => इनटू, फ्रॉम => ट्राईफ्रॉम, ट्राईफ्रॉम => ट्राईइन्टो, और इनटू => ट्राईइन्टो होना असंभव है।

यह सिर्फ गलत है, बस प्रस्तावित कार्यान्वयन को देखें।

यह वाला:
From -> Into -> TryFrom -> TryInto

From ऑटो-इम्प्ल्स Into
Into ऑटो-इम्प्ल्स TryFrom
TryFrom ऑटो-इम्प्ल्स TryInto

विस्तार से, ट्रांजिटिव ऑटो-इम्पल्स के कारण हमें मिलता है
From का अर्थ है TryFrom (क्योंकि From ऑटो का अर्थ है Into और Into ऑटो का अर्थ है TryFrom )
Into का अर्थ है TryInto (क्योंकि Into ऑटो का अर्थ है TryFrom और TryFrom ऑटो का अर्थ है TryInto )
प्रत्येक 1 स्तर के संकेत के साथ (मुझे लगता है कि यह ठीक है)

तो मेरी सभी शर्तें पूरी हो गई हैं।
हमारे पास सब हो सकता है

इम्पल | अप्रत्यक्ष स्तर
-----------------------|---------------------
From का अर्थ है Into | कोई संकेत नहीं
TryFrom का अर्थ है TryInto | कोई संकेत नहीं
From का अर्थ है TryFrom | अप्रत्यक्ष का 1 स्तर
Into का अर्थ है TryInto | अप्रत्यक्ष का 1 स्तर

From -> Into -> TryInto -> TryFrom
भी काम करेगा, लेकिन मैं निरंतरता बनाए रखना चाहता हूं और मूल संस्करण (ऊपर देखा गया) इस संस्करण की तुलना में अधिक सुसंगत है

शब्दावली पर ध्यान दें: (जब मैं उनका उपयोग करता हूं)

-> का अर्थ है ऑटो इम्प्लांट
ऑटो इम्प्लांट उस वास्तविक इम्प्लांट को संदर्भित करता है जिसमें टाइप किया गया है।
इसका मतलब है कि अगर मेरे पास यह इम्प्लांट है तो मुझे वह इम्प्लांट भी मिलेगा

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

पुल अनुरोध

@ कृष्णासनसी आह, अब मैं तुम्हारा बिंदु देखता हूं। हां, यह समझ में आता है और अब मैं देखता हूं कि आपका प्रस्तावित परिवर्तन समस्या को कैसे हल करता है और वांछित व्यवहार प्रदान करता है। विस्तृत व्याख्या के लिए धन्यवाद!

संपादित करें : ठीक है, रुको, हालांकि... मुझे अभी भी समझ में नहीं आता कि वर्तमान कंबल इम्प्लांट पर्याप्त क्यों नहीं हैं। संभावित रूप से एक ऐसा मामला है जहां आप Into लागू करने में सक्षम होंगे लेकिन From नहीं? और फिर भी TryFrom को स्वतः प्राप्त करना संभव है?

संपादित करें 2 : ठीक है, मैं अभी वापस गया और आपके स्पष्टीकरण को पढ़ा कि कैसे अनाथ नियम From के कार्यान्वयन को रोक सकता है। अब सब समझ आ रहा है। मैं इस बदलाव का पूरा समर्थन करता हूं। यह अभी भी थोड़ा निराशाजनक है कि अनाथ शासन के इतने सारे अनपेक्षित परिणाम हैं, लेकिन हम इसे यहां ठीक नहीं करने जा रहे हैं, इसलिए यह सर्वोत्तम चीजों को बनाने के लिए समझ में आता है।

क्या कोई @rust-lang/libs से शुरू करने के लिए तैयार होगा FCP इस पर अब https://github.com/rust-lang/rust/issues/49593 तय कर दिया गया है और never_type स्थिरीकरण के लिए एक उम्मीदवार है एक बार फिर?

इस सुविधा के माध्यम से पहले से ही चला गया है FCP स्थिरीकरण के लिए. ( प्रस्ताव , पूर्णता ।) मुझे लगता है कि 10 दिनों की टिप्पणी अवधि के माध्यम से जाना जरूरी नहीं है।

स्थिरीकरण पीआर के बाद कभी नहीं उतरा है, हम TryFrom / TryInto के लिए एक (नया) स्थिरीकरण पीआर बना सकते हैं और यह सुनिश्चित करने के लिए rfcbot का उपयोग कर सकते हैं कि टीम के सदस्य इसे देखें।

क्या मौजूदा खाली एनम प्रकारों जैसे FromStringError को उपनाम से ! में स्थिरीकरण के साथ बदलना संभव होगा?

@clarcharr हाँ। विशेषता निहित सुसंगतता के कारण, हम केवल एक प्रकार के लिए ऐसा कर पाते हैं। सौभाग्य से, हमारे पास केवल std::string::ParseError है। (और यही कारण है कि हमने https://github.com/rust-lang/rust/pull/55148 में impl FromString for PathBuf के लिए एक नया प्रकार जोड़ने के बजाय इसका इस्तेमाल किया।)

हालांकि यह TryFrom / TryInto से असंबंधित है। यह https://github.com/rust-lang/rust/issues/49691 / https://github.com/rust-lang/rust/issues/57012 के लिए एक विषय है, क्योंकि इसे उसी रिलीज चक्र में होने की आवश्यकता है ! के स्थिरीकरण के रूप में।

@SimonSapin क्या यह स्थिर होने से पहले मेरे पुल अनुरोध (# 56796) को मर्ज करना संभव होगा?

ज़रूर, मैंने इसे समस्या विवरण में जोड़ दिया है ताकि हम ट्रैक न खोएं।

धन्यवाद!

क्या इसे स्थिर में एकीकृत किया जा सकता है? यह CloudABI के लिए argdata की निर्भरता है।

@mcandre हाँ। यह वर्तमान में https://github.com/rust-lang/rust/issues/57012 पर प्रतीक्षा कर रहा है, जिसे हाल ही में अनब्लॉक किया गया था। मुझे उम्मीद है कि TryFrom इसे जंग 1.33 या 1.34 में बना देगा।

मैं इसके इंतजार में थक गया हूं और मेरे पास खाली समय है (आखिरकार)। अगर कोई कोड या दस्तावेज़ीकरण प्रकार की सामग्री है जो मैं इसे आगे बढ़ाने के लिए कर सकता हूं, तो मैं स्वेच्छा से मदद करता हूं।

56796 का विलय कर दिया गया है। तो हम इसे चेक कर सकते हैं।

@icefoxen मुझे लगता है कि अभी आप इन लक्षणों के दस्तावेज़ों के बारे में फीडबैक (और परिवर्तन) प्रदान करना सबसे अच्छा कर सकते हैं। अभी मैं उन्हें From और Into लक्षणों की तुलना में थोड़ा कम पाता हूं।

दस्तावेज पर काम कर रहे हैं। मामूली सड़क-टक्कर: मैं assert_eq!(some_value, std::num::TryFromIntError(())); चाहता हूं। हालांकि, चूंकि TryFromIntError में कोई कंस्ट्रक्टर नहीं है और कोई सार्वजनिक क्षेत्र नहीं है, मैं इसका उदाहरण नहीं बना सकता। आगे बढ़ने के बारे में कोई सलाह? अभी के लिए मैं सिर्फ assert!(some_value_result.is_err()); कर रहा हूं।

क्षमा करें अगर यह गलत जगह है, लेकिन ऐसा लगता है कि TryFromIntError के दस्तावेज़ों में कोई गलती है - यह impl Debug for TryFromIntError सूचीबद्ध करता है, जब वास्तव में इसके लिए कोई कोड नहीं होता है। एक TryFrom उपयोग से परिणाम को खोलने का प्रयास करते समय संकलक वर्तमान में एक त्रुटि उत्पन्न करता है।

क्या इस पर fmt::Debug लागू होने का मतलब है?

@marco9999

#[derive(Debug, Copy, Clone, PartialEq, Eq)]
pub struct TryFromIntError(());

इसमें #[derive(Debug)] विशेषता है।

हम्म हाँ है... क्या कुछ ठीक से काम नहीं कर रहा है?

error[E0599]: no method named `unwrap` found for type `std::result::Result<usize, <T as std::convert::TryInto<usize>>::Error>` in the current scope
  --> src\types\b8_memory_mapper.rs:67:51
   |
67 |         let address: usize = T::try_into(address).unwrap();
   |                                                   ^^^^^^
   |
   = note: the method `unwrap` exists but the following trait bounds were not satisfied:
           `<T as std::convert::TryInto<usize>>::Error : std::fmt::Debug`

@ marco9999 आप शायद एक सामान्य बाधा खो रहे हैं। TryFromIntError केवल कुछ प्रकारों द्वारा उपयोग किया जाता है, लेकिन आपका टी कुछ भी हो सकता है:

fn foo<T: TryInto<u8>>(x: T) -> u8
where
    <T as TryInto<u8>>::Error: Debug,
{
    x.try_into().unwrap()
}

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

मुझे assert_eq!(some_value, std::num::TryFromIntError(())); चाहिए

@icefoxen TryFromIntError से जुड़ा कोई उपयोगी मूल्य नहीं है, इसलिए इस तरह के दावे का अधिक मूल्य नहीं लगता है। यदि आपके पास Result<_, TryFromIntError> है और यह Err है, तो इसका कोई अन्य मूल्य नहीं हो सकता है।

assert!(some_value_result.is_err());

यह मुझे उचित लगता है।

क्रॉस-रेफ़रेंसिंग: https://github.com/rust-lang/rust/pull/58302

धन्यवाद @glaebhoerl।

एक अवरुद्ध बग के ठीक होने के कारण (https://github.com/rust-lang/rust/issues/49593) मैं उम्मीद कर रहा था कि कभी भी प्रकार को जल्द ही स्थिर नहीं किया जा सकता है https://github.com/rust-lang/ जंग/मुद्दों/57012 और इसे अनब्लॉक करें। हालाँकि एक नया मुद्दा (https://github.com/rust-lang/rust/issues/57012#issuecomment-460740678) सामने आया है, और हम एक दूसरे पर भी आम सहमति नहीं रखते हैं (https://github.com /जंग-लंग/जंग/मुद्दे/57012#इश्यू कमेंट-449098855)।

तो पिछले हफ्ते एक libs बैठक में मैंने फिर से विचार लाया, मेरा मानना ​​​​है कि पहले @scottmcm द्वारा प्रस्तावित https://github.com/rust-lang/rust/issues/33417#issuecomment -299124605, TryFrom को स्थिर करने के लिए TryInto बिना किसी प्रकार के, और इसके बजाय एक खाली एनम है जिसे बाद में एक उपनाम बनाया जा सकता है ! ।

पिछली बार हमने इस पर चर्चा की थी (https://github.com/rust-lang/rust/issues/33417#issuecomment-423069246), हमें याद नहीं आया कि हमने पिछली बार ऐसा क्यों नहीं किया था।

पिछले हफ्ते @dtolnay ने हमें इस मुद्दे की याद दिला दी: ! एक पूर्ण प्रकार बनने से पहले, यह पहले से ही फ़ंक्शन के रिटर्न प्रकार के स्थान पर उपयोग किया जा सकता है यह इंगित करने के लिए कि यह कभी वापस नहीं आता है। इसमें फ़ंक्शन पॉइंटर प्रकार शामिल हैं। तो, इस चक्र में https://github.com/rust-lang/rust/pull/58302 भूमि मानते हुए, इस तरह का कोड जंग 1.34.0 में मान्य होगा:

use std::convert::Infallible;
trait MyTrait {}
impl MyTrait for fn() -> ! {}
impl MyTrait for fn() -> Infallible {}

चूंकि fn() -> ! और fn() -> Infallible दो अलग-अलग (सूचक) प्रकार हैं, इसलिए दो इम्प्लांट ओवरलैप नहीं होते हैं। लेकिन अगर हम खाली एनम को pub type Infallible = !; प्रकार के उपनाम से बदल देते हैं (जब ! एक पूर्ण प्रकार बन जाता है), तो दो इम्प्लांट ओवरलैप होने लगेंगे और उपरोक्त जैसा कोड टूट जाएगा।

तो एनम को उपनाम में बदलना एक ब्रेकिंग बदलाव होगा। सिद्धांत रूप में हम इसे मानक पुस्तकालय में अनुमति नहीं देंगे, लेकिन इस मामले में हमने महसूस किया कि:

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

इस चर्चा के आधार पर, मैंने https://github.com/rust-lang/rust/pull/58302 सबमिट किया जो अब अंतिम टिप्पणी अवधि में है।

58015 अब समीक्षा/विलय के लिए तैयार होना चाहिए।

@kennytm क्या पहले से ही स्थिर में ! को संदर्भित करना संभव नहीं है? उदाहरण के लिए, निम्नलिखित पर विचार करें:

trait MyTrait {
    type Output;
}

impl<T> MyTrait for fn() -> T {
    type Output = T;
}

type Void = <fn() -> ! as MyTrait>::Output;

ऐसा करने के बाद, Void ! प्रकार को संदर्भित करता है।

यह एक बग जैसा दिखता है, जिसका अर्थ है कि स्थिरता की गारंटी इसका विस्तार नहीं करती है। नेवर टाइप ( ! ) का उपयोग किसी भी क्षमता में एक प्रकार के रूप में अभी भी अस्थिर है, कम से कम #57012 विलय होने तक।

मैं दस्तावेज़ीकरण में कैसे मदद कर सकता हूँ? :-)

ओह, मैंने सोचा था कि https://github.com/rust-lang/rust/pull/58015 उतरा था, लेकिन यह अभी तक नहीं आया है... आइए इसकी चर्चा करें।

क्या TryFrom विशेषता में यह जांचने का एक तरीका हो सकता है कि क्या तर्क को बिना उपभोग किए परिवर्तित किया जा सकता है?

fn check(value: &T) -> bool

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

उफ़ इसे https://github.com/rust-lang/rust/pull/58302 द्वारा बंद कर दिया जाना चाहिए था। अब बंद हो रहा है।

@ o01eg गैर-खपत रूपांतरण करने का सामान्य तरीका लागू करना है जैसे TryFrom<&'_ Foo> के बजाय TryFrom<Foo> ।

रुको...यह वास्तव में स्थिर गुरुवार को उतरने तक बंद नहीं होना चाहिए, है ना?

नहीं, जब पीआर फीचर को स्थिर करता है तो हम ट्रैकिंग मुद्दों को बंद कर देते हैं।

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

ट्रैकिंग मुद्दों को पीआर द्वारा बंद कर दिया जाता है जो उन्हें स्थिर करता है। रिलीज चक्र के आधार पर, स्थिर रिलीज होने से पहले यह 12 सप्ताह तक हो सकता है।

समझ लिया। स्पष्टीकरण के लिए धन्यवाद, सब लोग! :)

@gregdegruy जंग के अपने संस्करण को 1.34 या उच्चतर पर अपडेट करें।