Rust: RFC 1937 के लिए ट्रैकिंग समस्या: `?` `मुख्य` . में

बाहर निकलने की स्थिति से कैसे निपटा जाएगा?

@Screwtapello की यह टिप्पणी लगता है कि इसके अंत के बहुत करीब की गई है FCP इसके जवाब में RFC में किए जाने वाले किसी भी परिवर्तन के लिए।

संक्षेप में: RFC ने विफलता पर 2 को इस आधार पर वापस करने का प्रस्ताव किया है, जो अच्छी तरह से स्थापित होने के बावजूद अस्पष्ट हैं और थोड़ा असामान्य परिणाम देते हैं; कम से कम आश्चर्य की बात यह है कि 1 को वापस करना है जब कार्यक्रम का कोई संकेत नहीं है, यह केवल सफलता या विफलता के अलावा और अधिक विवरण चाहता है। क्या यह पर्याप्त रूप से बाइकशेडी है कि इस पर चर्चा किए बिना यह महसूस किया जा सकता है कि हम आरएफसी प्रक्रिया को विकृत कर रहे हैं, या अब हम इस विशिष्ट कार्यान्वयन विवरण में बंद हैं?

हालांकि यह एक कार्यान्वयन विवरण नहीं है, है ना?

कुछ स्क्रिप्ट उप-प्रक्रिया से जानकारी प्राप्त करने के तरीके के रूप में निकास कोड का उपयोग करती हैं।

यह विशेष रूप से उस मामले के बारे में है जब एक उप-प्रक्रिया (जंग में लागू) के पास बाइनरी "सब कुछ ठीक है"/"कुछ गलत हो गया" से परे देने के लिए कोई जानकारी नहीं है।

कुछ स्क्रिप्ट उप-प्रक्रिया से जानकारी प्राप्त करने के तरीके के रूप में निकास कोड का उपयोग करती हैं।

वह व्यवहार हमेशा उस कार्यक्रम पर अत्यधिक निर्भर होता है जिसे _except_ कहा जाता है, उस गैर-शून्य का अर्थ है विफलता। यह देखते हुए कि std::process::exit एक मुख्य-फ़ंक्शन रैपर और एक लुकअप टेबल के साथ उन लोगों के लिए सबसे अच्छा विकल्प बना रहेगा जो अधिक स्पष्ट निकास स्थिति चाहते हैं चाहे कुछ भी किया जाए, यह ज्यादातर महत्वहीन विवरण की तरह लगता है।

मुझे नहीं लगता कि SemVer में "ज्यादातर महत्वहीन विवरण" अपवाद है।

मुझे लगता है कि एक्जिट कोड को अनसुलझे प्रश्नों की सूची में जोड़ा जाना चाहिए। @zackw ने एक संबंधित इंटर्नल थ्रेड भी खोला।

बहुत से लोग सहमत हैं कि विफलता पर निकास कोड 1 होना चाहिए (बजाय 2 ):
https://www.reddit.com/r/rust/comments/6nxg6t/the_rfc_using_in_main_just_got_merged/

@ arielb1 क्या आप इस rfc को लागू करने जा रहे हैं?

@bkchr

नहीं, बस इसका मार्गदर्शन करने के लिए। मैंने असाइन किया है इसलिए मैं मेंटरिंग नोट्स लिखना नहीं भूलूंगा।

आह अच्छा, मुझे इसे करने में दिलचस्पी होगी :)
लेकिन, मुझे नहीं पता कि कहां से शुरू करूं :D

@bkchr

इसलिए मैं यहां हूँ :-)। मुझे मेंटरिंग निर्देश जल्द ही लिखने चाहिए।

ठीक है, तो मैं आपके निर्देशों की प्रतीक्षा कर रहा हूँ।

सलाह निर्देश

यह एक [डब्ल्यूजी-कंपाइलर-मध्य] मुद्दा है। अगर आप मदद लेना चाहते हैं, तो आप irc.mozilla.org (I'm arielby) पर #rustc से जुड़ सकते हैं या https://gitter.im/rust-impl-period/WG-compiler-middle (मैं @arielb1 हूं) वहां)।

#44505 पर एक WIP कंपाइलर रीडमी है - यह कंपाइलर में कुछ चीजों का वर्णन करता है।

इस आरएफसी के लिए कार्य योजना:

• [ ] - Termination लैंग-आइटम को libcore में जोड़ें
• [ ] - Termination में main . का उपयोग करने की अनुमति दें
• [ ] - सिद्धांतों में Termination का उपयोग करने की अनुमति दें
• [ ] - #[test] . में #[test] Termination का उपयोग करने की अनुमति दें

Termination लैंग-आइटम को libcore में जोड़ें

सबसे पहले, आपको कुछ दस्तावेज़ों के साथ Termination विशेषता को libcore/ops/termination.rs में जोड़ना होगा। आपको #[unstable(feature = "termination_trait", issue = "0")] विशेषता के साथ इसे अस्थिर के रूप में चिह्नित करने की भी आवश्यकता होगी - यह लोगों को इसके स्थिर होने से पहले इसका उपयोग करने से रोकेगा।

फिर, आपको इसे src/librustc/middle/lang_items.rs में लैंग-आइटम के रूप में चिह्नित करना होगा। इसका मतलब है कि कंपाइलर main टाइप-चेक करते समय इसका पता लगा सकता है (उदाहरण के लिए 0c3ac648f85cca1e8dd89dfff727a422bc1897a6 देखें)।
इसका मत:

1. इसे लैंग-आइटम सूची में जोड़ना ( librustc/middle/lang_items.rs में)
2. #[cfg_attr(not(stage0), lang = "termination")] को Termination विशेषता में जोड़ना। आप केवल #[lang = "termination"] विशेषता नहीं जोड़ सकते, इसका कारण यह है कि "स्टेज0" कंपाइलर (बूटस्ट्रैपिंग के दौरान) को पता नहीं चलेगा कि termination कुछ ऐसा है जो मौजूद है, इसलिए यह सक्षम नहीं होगा libstd संकलित करें। जब हम स्टेज0 कंपाइलर को अपडेट करेंगे तो हम मैन्युअल रूप से cfg_attr को हटा देंगे।
   विवरण के लिए XXX पर बूटस्ट्रैपिंग दस्तावेज़ देखें।

मुख्य में Termination का उपयोग करने की अनुमति दें

यह दिलचस्प हिस्सा है जिसे मैं जानता हूं कि कैसे निपटना है। इसका मतलब है कि एक main बनाना जो () लौटाता है न कि टाइप-चेक (वर्तमान में आपको main function has wrong type त्रुटि मिलती है) और काम करें।

इसे टाइप-चेक करने के लिए, आपको पहले मौजूदा त्रुटि को दूर करना होगा:
https://github.com/rust-lang/rust/blob/9a00f3cc306f2f79bfbd54f1986d8ca7a74f6661/src/librustc_typeck/lib.rs#L171 -L218

फिर, आपको एक चेक जोड़ने की आवश्यकता है कि रिटर्न प्रकार Termination विशेषता को लागू करता है (आप register_predicate_obligation का उपयोग करके एक विशेषता दायित्व जोड़ते हैं - इसके उपयोग के लिए खोजें)। यह यहाँ किया जा सकता है:
https://github.com/rust-lang/rust/blob/9a00f3cc306f2f79bfbd54f1986d8ca7a74f6661/src/librustc_typeck/check/mod.rs#L1100 -L1108

दूसरा हिस्सा इसे काम कर रहा है। यह अपेक्षाकृत आसान होना चाहिए। जैसा कि आरएफसी कहता है, आप रिटर्न प्रकार पर lang_start सामान्य बनाना चाहते हैं।

lang_start वर्तमान में यहां परिभाषित किया गया है:
https://github.com/rust-lang/rust/blob/9a00f3cc306f2f79bfbd54f1986d8ca7a74f6661/src/libstd/rt.rs#L32

तो आपको इसे सामान्य होने और RFC से मेल खाने के लिए बदलना होगा:

#[lang = "start"]
fn lang_start<T: Termination>
    (main: fn() -> T, argc: isize, argv: *const *const u8) -> !
{
    use panic;
    use sys;
    use sys_common;
    use sys_common::thread_info;
    use thread::Thread;

    sys::init();

    sys::process::exit(unsafe {
        let main_guard = sys::thread::guard::init();
        sys::stack_overflow::init();

        // Next, set up the current Thread with the guard information we just
        // created. Note that this isn't necessary in general for new threads,
        // but we just do this to name the main thread and to give it correct
        // info about the stack bounds.
        let thread = Thread::new(Some("main".to_owned()));
        thread_info::set(main_guard, thread);

        // Store our args if necessary in a squirreled away location
        sys::args::init(argc, argv);

        // Let's run some code!
        let exitcode = panic::catch_unwind(|| main().report())
            .unwrap_or(101);

        sys_common::cleanup();
        exitcode
    });
}

और फिर आपको इसे create_entry_fn से कॉल करना होगा। वर्तमान में, यह Instance::mono का उपयोग करके एक मोनोमोर्फिक lang_start Instance::mono इंस्टेंट करता है, और आपको इसे सही विकल्प के साथ monomorphize::resolve का उपयोग करने के लिए बदलना होगा।

https://github.com/rust-lang/rust/blob/9a00f3cc306f2f79bfbd54f1986d8ca7a74f6661/src/librustc_trans/base.rs#L697

सिद्धांतों में Termination का उपयोग करने की अनुमति दें

मैं वास्तव में समझ नहीं पा रहा हूं कि doctests कैसे काम करता है। शायद @alexcrichton से पूछें (मैं यही करूंगा)?

Termination में #[test] . का उपयोग करने की अनुमति दें

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

@bkchr

क्या आप कम से कम आईआरसी/गटर में शामिल हो सकते हैं?

@bkchr अभी चेक इन कर रहा है - मैंने देखा कि आप और @ arielb1 कुछ समय पहले गटर पर बातचीत कर रहे थे, कोई प्रगति? कहीं चूसो?

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

@bkchr अगर आपको कुछ मदद चाहिए तो मुझे बताएं!

मैं वर्तमान में थोड़ा फंस गया हूँ, मैं दायित्व बनाना चाहता हूँ। दायित्व बनाने के लिए मुझे एक TraifRef की आवश्यकता है, एक TraitRef के लिए मुझे एक DefId की आवश्यकता है। क्या कोई मुझे टर्मिनेशन ट्रैट से DefId बनाने के तरीके के बारे में कुछ कोड बता सकता है?

@bkchr विशेषता को लैंग आइटम सूची में जोड़ा जाना चाहिए, जैसे: https://github.com/rust-lang/rust/blob/ade0b01ebf18550e41d24c6e36f91afaccd7f389/src/librustc/middle/lang_items.rs#L312
और #[termination_trait] के साथ चिह्नित करें, उदाहरण के लिए: https://github.com/rust-lang/rust/blob/ade0b01ebf18550e41d24c6e36f91afaccd7f389/src/libcore/fmt/mod.rs#L525 -L526

हाँ, यह समस्या नहीं है, मैंने पहले ही ऐसा कर लिया है। मुझे check_fn फ़ंक्शन में समाप्ति विशेषता की जांच करने की आवश्यकता है। मैं register_predicate_obligation का उपयोग करना चाहता हूं और इसके लिए मुझे टर्मिनेशन विशेषता के defid की आवश्यकता है।

ओह, तो आपको केवल tcx.require_lang_item(TerminationTraitLangItem) चाहिए।

@bkchr कैसे जाता है? बस फिर से जाँच कर रहा हूँ। =) यदि आप व्यस्त हैं तो चिंता की कोई बात नहीं है, बस यह सुनिश्चित करना चाहते हैं कि आपको वह सभी सहायता मिल रही है जिसकी आपको आवश्यकता है।

क्षमा करें, इस समय व्यस्त हैं :/ अब तक, मुझे वह सब सहायता मिली जिसकी मुझे आवश्यकता थी :)

टर्मिनेशनट्रेट की जांच के लिए यह कोड है: https://github.com/bkchr/rust/blob/f185e355d8970c3350269ddbc6dfe3b8f678dc44/src/librustc_typeck/check/mod.rs#L1108

मुझे लगता है कि मैं फ़ंक्शन के रिटर्न प्रकार की जांच नहीं कर रहा हूं? मुझे निम्नलिखित त्रुटि मिलती है:

error[E0277]: the trait bound `Self: std::ops::Termination` is not satisfied
  --> src/rustc/rustc.rs:15:11
   |
15 | fn main() { rustc_driver::main() }
   |           ^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::ops::Termination` is not implemented for `Self`
   |
   = help: consider adding a `where Self: std::ops::Termination` bound

फ़ंक्शन के रिटर्न प्रकार की जांच करने के लिए मुझे क्या बदलने की आवश्यकता है?

@bkchr मैं फीडबैक के लिए https://gitter.im/rust-impl-period/WG-compiler-middle पर कंपाइलर-मिडिल वर्किंग ग्रुप गटर में शामिल होने की सलाह दूंगा, साथ ही https पर #rust-internals IRC चैनल को आज़माने की सलाह दूंगा। ://chat.mibbit.com/?server=irc.mozilla.org%3A%2B6697&channel=%23rust-internals। :)

@bstree हाँ धन्यवाद, मैं पहले से ही गटर चैट का हिस्सा हूं और मेरी समस्या का समाधान कर सकता है। :)

@bkchr आपकी समस्या इस लाइन पर है। आप जिस विशेषता संदर्भ का निर्माण करना चाहते हैं वह R: Termination जैसा कुछ है जहां R फ़ंक्शन का रिटर्न प्रकार है। यह एक उपयुक्त "पदार्थ" बनाकर निर्दिष्ट किया जाता है, जो विशेषता के प्रकार के मापदंडों (इस मामले में, Self ) के स्थान पर मूल्यों का सेट है।

हालाँकि, आप विशेषता पर Substs::identity_for_item पद्धति लागू कर रहे हैं। यह आपको उन प्रतिस्थापनों को वापस देगा जो एक विशेषता परिभाषा के अंदर ही उपयोग करेगा। यानी, इस मामले में आप Self Termination #$ पैरामीटर को Self पर मैप कर रहे हैं। यह उचित होगा यदि आप Terminator विशेषता के अंदर किसी फ़ंक्शन की परिभाषा की जाँच कर रहे थे, लेकिन यहाँ इतना नहीं।

इसके बजाय आप जो चाहते हैं वह एंट्री फ़ंक्शन का रिटर्न प्रकार प्राप्त करना है। यह ret_ty या actual_ret_ty चरों में से एक है। या तो ठीक है, लेकिन मुझे लगता है कि ret_ty बेहतर है - जो उपयोगकर्ता द्वारा घोषित रिटर्न प्रकार से मेल खाता है (जबकि actual_ret_ty वास्तविक कोड लौटाया गया प्रकार है)।

आप tcx से केवल mk_substs() विधि को कॉल करके अपने इच्छित पदार्थ बना सकते हैं। इस मामले में, केवल एक पैरामीटर है, प्रकार, इसलिए let substs = fcx.tcx.mk_substs(&[ret_ty]); जैसा कुछ काम करेगा, मुझे लगता है।

मेरा मानना ​​​​है कि उपयोग करने वाली चीज़ tcx.mk_substs_trait(ret_ty, &[]) है।

@bkchr बस जाँच कर रहा है - उस सलाह को उपयोग करने का मौका मिला? (इसके अलावा, तेजी से प्रतिक्रियाओं के लिए, गटर पर पूछना बुद्धिमानी हो सकती है।)

हाँ, मैं गटर के साथ समस्या का समाधान कर सकता हूँ :)

@bkchr कैसे जाता है? बस चेक इन कर रहा है।

सब कुछ ठीक है, मुझे शायद इस सप्ताह कोड देखने के लिए कुछ समय मिलेगा।

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

@ यू007डी

यह एक छोटी सी विशेषता है और @bkchr लगभग पूरा हो चुका है।

आह, ठीक है - यह जानना अच्छा है, धन्यवाद। मैं किसी और चीज़ पर नज़र रखूँगा जिसमें मैं मदद कर सकता हूँ।

@ U007D क्या आपने https://www.rustaceans.org/findwork देखा है?

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

वैसे भी, इस साल कुछ चुनना और कम से कम सकारात्मक योगदान देना शुरू करना मेरा लक्ष्य है। मेरे लिए इसमें शामिल होने का समय आ गया है! :)

सुझाव के लिए धन्यवाद, @lnicola। यह एक अच्छा संसाधन है।

@bkchr कोई अपडेट?

मैं इस पर हूं (https://github.com/rust-lang/rust/pull/46479)। अब मेरे पास पुल अनुरोध में टिप्पणियों में काम करने के लिए छुट्टियां और समय है। सभी देरी के लिए खेद है: /

ओह, क्षमा करें, आपने ध्यान नहीं दिया कि आपके पास एक पुल अनुरोध था। इसे क्रॉस-लिंक किया।

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

• [ ] विशेषता का नाम पेश किया जा रहा है

कैसे के बारे में Exit ? यह मौजूदा रस्ट शब्दावली को फिट करने के लिए संक्षिप्त और बिंदु पर है। Exit-as-a-noun, exit-as-a-verb के लिए एक प्राकृतिक प्रतिरूप है, जो कि अधिकांश के लिए, एक नियंत्रित तरीके से "अंदर से" प्रक्रिया को समाप्त करने के लिए परिचित शब्द है।

सी ++ प्रोग्रामर के लिए विशेष रूप से, "टर्मिनेशन" std::terminate को ध्यान में रखता है जो असामान्य समाप्ति (कॉलिंग abort ) के लिए डिफ़ॉल्ट है और मूल रूप से सी ++ एक आतंक के बराबर है (लेकिन एक आतंक के विपरीत, कभी भी तनाव को कम नहीं करता है) ढेर)।

रुको, उस टिप्पणी को अनदेखा करें, ऐसा लगता है कि RFC छोड़ दिया गया है जो स्पष्ट रूप से चर्चा के लिए खुला है।

मुझे विशेषता नाम के रूप में Exit पसंद है।

मुझे लग रहा है कि विशेषता के होने से बहुत पहले यह सुविधा स्थिर हो जाएगी, जैसा कि Carrier के साथ हुआ था।

एफडब्ल्यूआईडब्ल्यू यह एक और मामला है जहां मुझे वास्तव में खुशी है कि स्थिरीकरण से पहले अस्थायी नाम बदल दिया गया था: डी

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

https://github.com/rust-lang/rust/blob/5f7aeaf6e2b90e247a2d194d7bc0b642b287fc16/src/libstd/lib.rs#L507

क्या गुण होना चाहिए

1. libcore के बजाय libstd में रखा गया है, और
2. बस std::Termination कहा जाता है, std::ops::Termination नहीं?

विशेषता को libcore में नहीं रखा जा सका, क्योंकि Result के कार्यान्वयन के लिए Result पर प्रिंट करने की आवश्यकता है और यह stderr libcore में नहीं किया जा सकता है।

@bkchr libstd में होने का मतलब यह नहीं है कि विशेषता को libstd में भी होना चाहिए।

@kennytm मुझे पता है, लेकिन परिणाम libcore में भी परिभाषित किया गया है, इसलिए libstd में परिणाम के लिए समाप्ति को लागू नहीं किया जा सकता है।

@zackw +1 अधिक वोट के लिए Exit विशेषता नाम के रूप में।

@ U007D : क्या आप कृपया ऐसा संदेश पोस्ट करने के बजाय प्रतिक्रिया बटन (जैसे, ) का उपयोग कर सकते हैं? यह आपको अनावश्यक रूप से पिंग करके ग्राहकों को परेशान करने वाली समस्या से बचने देगा।

क्या मैं चेक इन कर सकता हूँ libtest / libsyntax , अगर language_feature सक्रिय है (एक टोकरा में)? @arielb1 @nikomatsakis @alexcrichton

@bkchr libsyntax में आपको इसे पास करना पड़ सकता है लेकिन यह सिद्धांत रूप में संभव है, लेकिन रनटाइम पर ही libtest में मुझे विश्वास नहीं है कि आप जांच कर सकते हैं।

@bkchr यहाँ कैसे जाता है?

मैं अभी भी इस पर काम कर रहा हूं, लेकिन वर्तमान में मेरे पास और प्रश्न नहीं हैं :)

मुझे लगता है कि यह निहितार्थ बहुत सख्त है:

#[unstable(feature = "termination_trait", issue = "43301")]
impl<T: Termination, E: Error> Termination for Result<T, E> {
    fn report(self) -> i32 {
        match self {
            Ok(val) => val.report(),
            Err(err) => {
                print_error(err);
                exit::FAILURE
            }
        }
    }
}


#[unstable(feature = "termination_trait", issue = "43301")]
fn print_error<E: Error>(err: E) {
    eprintln!("Error: {}", err.description());

    if let Some(ref err) = err.cause() {
        eprintln!("Caused by: {}", err.description());
    }
}

आमतौर पर उपयोग की जाने वाली कई त्रुटियां हैं जो Error को लागू नहीं करती हैं, सबसे महत्वपूर्ण Box<::std::error::Error> और failure::Error । मुझे यह भी लगता है कि इस त्रुटि के प्रदर्शन निहितार्थ के बजाय description पद्धति का उपयोग करना एक गलती है।

मैं इस आशय को इस व्यापक अर्थ से बदलने का प्रस्ताव करता हूँ:

#[unstable(feature = "termination_trait", issue = "43301")]
impl<T: Termination, E: Display> Termination for Result<T, E> {
    fn report(self) -> i32 {
        match self {
            Ok(val) => val.report(),
            Err(err) => {
                eprintln!("Error: {}", err)
                exit::FAILURE
            }
        }
    }
}

यह कारण श्रृंखला खो देता है जो एक बमर है।

हालांकि विवरण के बजाय डिस्प्ले इंपैक्ट का उपयोग करना निश्चित रूप से बेहतर काम है।

कारण श्रृंखला एक दिलचस्प समस्या है। विशेष रूप से, यह कार्यान्वयन केवल कारण श्रृंखला के पहले दो सदस्यों को प्रिंट करता है।

विफलता को कारण श्रृंखला को संभालने के तरीके से निपटना पड़ा और डिफ़ॉल्ट रूप से इस व्यवहार पर बस गया (उदाहरण के लिए यदि आप .context का उपयोग करके त्रुटियों का निर्माण करते हैं:

• {} केवल इस त्रुटि को प्रिंट करता है
• {:?} इस त्रुटि के साथ-साथ इसके कारण (पुनरावर्ती) को प्रिंट करता है

हम यहां :? का उपयोग करने का निर्णय ले सकते हैं और इसे डिस्प्ले के बजाय डीबग को बाध्य कर सकते हैं। अनिश्चित।

हाँ, मुझे पहले से ही पता है कि मुझे समर्थन के लिए इम्प्लांट में सुधार करने की आवश्यकता है। मैं खुला हूं कि हम क्या कर सकते हैं। Debug से जुड़ना एक अच्छा विचार हो सकता है।

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

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

@withboats मैं सहमत हूँ।

@nikomatsakis मुझे लगता है कि आपका मतलब है "जरूरी नहीं कि सबसे सुंदर रूप में"? यदि हां, तो मैं सहमत हूं।

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

:+1: यहां Debug पर; मुझे https://github.com/rust-lang/rfcs/pull/1937#issuecomment -284509933 से @nikomatsakis का "एक बेजोड़ अपवाद के समान" पसंद है। Diggsey की एक टिप्पणी भी Debug सुझाव दे रही है: https://github.com/rust-lang/rfcs/pull/1937#issuecomment -289248751

FYI करें, मैंने "अधिक पूर्ण" बनाम "अधिक उपयोगकर्ता के अनुकूल" डिफ़ॉल्ट (यानी Debug बनाम Display विशेषता बाध्य) मुद्दे पर फ़्लिप किया है।

टीएल; डीआर अब मुझे विश्वास है कि हमें 'कुछ भी नहीं' मामले में क्लीनर, सारांश आउटपुट प्रदान करने के लिए Display ( @withboats ' मूल पोस्ट के अनुसार) पर बाध्य होना चाहिए।

यहाँ मेरा तर्क है:

termination विशेषता के RFC मुद्दे पर @zackw सम्मोहक बिंदु बनाता है कि रस्ट में दोहरी panic / Result प्रणाली है क्योंकि panic s बग के लिए हैं और Result s त्रुटियों के लिए हैं। इससे, मुझे लगता है कि डिफ़ॉल्ट पैनिक प्रस्तुति से स्वतंत्र रूप से डिफ़ॉल्ट त्रुटि प्रस्तुति का मूल्यांकन करने के लिए एक सम्मोहक मामला बनाया जा सकता है।

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

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

• जैसा कि @nikomatsakis ने बताया, हमारे द्वारा चुने गए डिफ़ॉल्ट की परवाह किए बिना, कोई भी डेवलपर जो व्यवहार को बदलना चाहता है, वह या तो नए प्रकार के पैटर्न का उपयोग कर सकता है या मुख्य () में एक कस्टम कार्यान्वयन विकसित कर सकता है।

और अंत में अधिक व्यक्तिपरक पक्ष पर, पिछले कुछ दिनों में इस सुविधा के साथ काम करने में, मैंने पाया है कि Debug आउटपुट ने मुझे यह महसूस कराया कि मेरा "रस्ट ऐप" अधिक बिना पॉलिश वाला लगा:

$ foo
Error: Custom { kind: Other, error: StringError("returned Box<Error> from main()") }
$

बनाम

$ foo
Error: returned Box<Error> from main()
$

Dispay विशेषता एक त्रुटि के लिए बहुत अधिक सभ्य डिफ़ॉल्ट प्रतीत होती है (बग के विपरीत), है ना?

@ U007D रुको, आप उन दो आउटपुट में से कौन सा पसंद करते हैं?

(ए) Error: Custom { kind: Other, error: StringError("returned Box<Error> from main()") }

या

(बी) Error: returned Box<Error> from main()

वह विकल्प (बी) पसंद करता है।

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

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

उन मामलों में, मेरे लिए "कम से कम आश्चर्य" एक डेवलपर-उन्मुख आउटपुट है जैसे unwrap ।

यदि लंबी त्रुटि के बारे में चिंता है, तो क्या यहां {:#?} पर चर्चा करना उचित होगा?

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

मुझे लगता है कि इस चर्चा का केंद्र वास्तव में "डिफ़ॉल्ट संदेश के लिए लक्षित दर्शक कौन है?"

आइए एक पल के लिए कहें कि हम सभी सहमत थे कि डिफ़ॉल्ट लक्षित दर्शक डेवलपर्स थे। मुझे लगता है कि Debug डिफ़ॉल्ट बाउंड एक सीधा विकल्प होगा।

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

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

(मैं इस पूरे विषय में पूरी तरह से वाकिफ नहीं हूं, लेकिन) क्या यह कल्पना योग्य नहीं है कि छोटी उपयोगिताएं हो सकती हैं जिसके लिए Termination के साथ डिफ़ॉल्ट त्रुटि आउटपुट पूरी तरह से पर्याप्त होगा, बशर्ते यह कुछ उपयोगकर्ता-प्रस्तुत करने योग्य प्रारूप में हो Display की तरह? उस स्थिति में, लेखकों को "कस्टम हैंडलिंग" के लिए पहुंचने का एकमात्र कारण यह है कि यदि हम उन्हें बनाते हैं।

क्या कोई उदाहरण प्रदान कर सकता है कि प्रत्येक मामले में आउटपुट कैसा दिखता है (मुझे लगता है कि यह विशेष E प्रकार के उपयोग पर भी निर्भर करता है?), और लेखकों को वास्तव में क्या कदम उठाने की आवश्यकता है यदि वे "कस्टम हैंडलिंग" चाहते हैं बजाय? मैं सिर्फ ऊपर काल्पनिक पर जा रहा हूँ।

(क्या आउटपुट सचमुच @ U007D जैसा दिखता है ऊपर चिपकाया गया है? यह "लौटा हुआ बॉक्स\" क्यों प्रिंट करेगाबॉक्स<त्रुटि>?)

त्रुटि संदेश का Display भी कितनी बार उपयोगकर्ता के अनुकूल है? उदाहरण के लिए, निम्नलिखित कार्यक्रम:

fn main() {
    if let Err(e) = std::fs::File::open("foo") {
        println!("{}", e)
    }
}

निम्नलिखित संदेश उत्सर्जित करता है:

No such file or directory (os error 2)

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

तो मुझे लगता है कि मैं जो कहने की कोशिश कर रहा हूं वह यह है कि पुस्तकालय त्रुटियों की सूचना सामग्री में सुधार किए बिना, न तो Debug और न ही Display महान है।

क्या आउटपुट सचमुच वैसा ही दिखता है जैसा @ U007D ऊपर चिपकाया गया है? यह "लौटा हुआ बॉक्स" क्यों प्रिंट करेगासे मुख्य ()" के बजाय... उस बॉक्स की वास्तविक सामग्री?

@glaebhoerl आप सही हैं - इस मामले में, "उस Box<Error> " की वास्तविक सामग्री एक कस्टम message फ़ील्ड थी जिसे मैंने termination_trait का परीक्षण करने के लिए बनाया था, शब्दशः प्रदर्शित किया गया था . मैं इसके बजाय "फू बार बाज" या वहां कुछ भी लिख सकता था (लेकिन हो सकता है कि यह संकलक परीक्षण चलाने वाले उपयोगकर्ता के लिए उतना उपयोगी न हो)।

@jdahlstrom के उदाहरण का उपयोग करते हुए, यहां Box एड मानक पुस्तकालय "फ़ाइल नहीं मिली" Error के लिए वास्तविक आउटपुट है (ध्यान दें, जैसा कि आप सही ढंग से इंगित करते हैं, कहीं भी मुक्केबाजी का कोई उल्लेख नहीं है):
Debug :

$ foo
Error { repr: Os { code: 2, message: "No such file or directory" } }
$

और Display :

$ foo
No such file or directory (os error 2)
$

@jdahlstrom मुझे लगता है कि आप एक अच्छी बात करते हैं। मैं इस बात से सहमत हूं कि दोनों संदेश अपने लक्षित दर्शकों को कमजोर कर सकते हैं और मैं इस बात पर प्रकाश डालना चाहता हूं कि गलत प्रदान करना और भी बुरा है (जैसा कि मुझे लगता है कि आपने इसका उल्लेख किया है):

किसी डेवलपर को Display प्रदान करने से Debug के सभी डाउनसाइड होते हैं और साथ ही किस प्रकार की त्रुटि प्रदर्शित की जा रही है, इसकी विशिष्टता याद आती है।

किसी उपयोगकर्ता को Debug प्रदान करने से Display के सभी नुकसान होते हैं और साथ ही वह और भी अधिक तकनीकी जानकारी जोड़ता है जिसकी उपयोगकर्ता को आवश्यकता नहीं होती है और हो सकता है कि वह समझने में सक्षम न हो।

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

मुझे ? में #[test] के समर्थन को लागू करने के लिए कुछ मदद की आवश्यकता है। मेरा वर्तमान कार्यान्वयन यहां पाया जा सकता है: https://github.com/rust-lang/rust/compare/master...bkchr:termination_trait_in_tests

मेरे परिवर्तनों के साथ एक परीक्षण संकलित करने से निम्न त्रुटि होती है:

error: use of unstable library feature 'test' (see issue #27812)
  |
  = help: add #![feature(test)] to the crate attributes to enable

@eddyb ने कहा कि मुझे अब quote_item!/expr! का उपयोग नहीं करना चाहिए, क्योंकि वे विरासत हैं।
अब मुझे क्या करना चाहिए, नए quote! मैक्रो पर स्विच करें या मैन्युअल एस्ट बिल्डिंग में सब कुछ फिर से काम करें?

मैं किसी भी मदद की सराहना करता हूं :)

मुझे लगता है कि libtest में परिभाषित कुछ मैक्रो के लिए मैक्रो आमंत्रण उत्पन्न करना बहुत अच्छा काम कर सकता है।

@eddyb मुझे यकीन नहीं है कि मैं यहां आपका सुझाव समझता हूं:

मुझे लगता है कि libtest में परिभाषित कुछ मैक्रो के लिए मैक्रो आमंत्रण उत्पन्न करना बहुत अच्छा काम कर सकता है।

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

@bkchr

मेरे परिवर्तनों के साथ एक परीक्षण संकलित करने से निम्न त्रुटि होती है:

क्या आपके पास कोई विचार है कि वह त्रुटि क्यों उत्पन्न हो रही है? बस अंतर पढ़ने से, मैं नहीं करता, लेकिन मैं स्थानीय रूप से निर्माण करने और इसे समझने की कोशिश कर सकता हूं।

मुझे अब quote_item!/expr! का उपयोग नहीं करना चाहिए, क्योंकि वे विरासत हैं।

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

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

अधिकतर हमें केवल एक छोटा सा संपादन करने की आवश्यकता है, है ना? यानी, report() के परिणाम का परीक्षण करने के लिए फ़ंक्शन को लागू करने से बदलें?

पुनश्च, हम शायद .report() संकेतन का उपयोग करने के बजाय Termination::report(...) जैसा कुछ उत्पन्न करना चाहते हैं, Termination विशेषता के दायरे में होने पर भरोसा करने से बचने के लिए?

नहीं, मुझे नहीं पता कि वह त्रुटि कहां से आ रही है :(

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

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

@alexcrichton क्या आपको शायद अंदाजा है कि यह त्रुटि कहां से आ रही है?

@nikomatsakis libtest अस्थिर है और क्या हम मैक्रोज़ को अस्थिर के रूप में चिह्नित नहीं कर सकते, भले ही वह नहीं थे?

@eddyb ओह, अच्छी बात है।

आरएफसी ने एक रैपर फ़ंक्शन उत्पन्न करने का प्रस्ताव रखा जो मूल परीक्षण फ़ंक्शन को कॉल करता है। ऐसा करने का मेरा वर्तमान तरीका भी यही है।

एक रैपर समारोह मुझे ठीक लगता है।

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

@bkchr मैक्रो परिभाषा पर #[unstable(...)] विशेषता डालना, जैसे: https://github.com/rust-lang/rust/blob/3a39b2aa5a68dd07aacab2106db3927f666a485a/src/libstd/thread/local.rs#L159 -L165

तो, क्या यह पहला चेकबॉक्स होना चाहिए ...

आरएफसी लागू करें

...अब जांच लें कि लिंक किए गए पीआर को मर्ज कर दिया गया है?

@ErichDonGubler हो गया :)

हम्म, यह वर्तमान में केवल आधा rfc है जिसे मर्ज किए गए pr ^^ . के साथ लागू किया गया है

3 चेकबॉक्स में अलग :)

मैं main में इस सुविधा का उपयोग करने की कोशिश कर रहा हूं और मुझे यह बहुत निराशाजनक लगा है। टर्मिनेशन विशेषता के मौजूदा निहितार्थ मुझे कई प्रकार की त्रुटियों को आसानी से "संचित" करने की अनुमति नहीं देते हैं - उदाहरण के लिए, मैं failure::Fail का उपयोग नहीं कर सकता, क्योंकि यह Error को लागू नहीं करता है Box<Error> का उपयोग नहीं कर सकता। मुझे लगता है कि हमें Debug में बदलने को प्राथमिकता देनी चाहिए। =)

हाय, @nikomatsakis ,

जब मैंने termination_trait का उपयोग करने का प्रयास किया तो मुझे बिल्कुल वैसी ही निराशा हुई जैसी आपने की थी।

संकलक पर हैकिंग पर आपकी पोस्ट के साथ संयुक्त रूप से मुझे इस महीने की शुरुआत में इस समस्या पर एक दरार लेने के लिए प्रेरित किया। मैंने यहां परीक्षणों के साथ Display (और पिछली प्रतिबद्धता में Debug के लिए) के लिए इम्प्लांट पोस्ट किया है: https://github.com/rust-lang/rust/pull/47544। (यह बहुत मामूली है, लेकिन फिर भी, मेरा पहला रस्ट कंपाइलर पीआर!: टाडा :) :)

मेरी समझ यह है कि लैंग टीम एक कॉल करेगी कि किस विशेषता के साथ जाना है, लेकिन किसी भी तरह से, कार्यान्वयन जाने के लिए तैयार है।

एक प्रश्न जिसमें मुझे अभी भी दिलचस्पी है: मान लीजिए कि आप डिफ़ॉल्ट त्रुटि संदेश आउटपुट (चाहे Debug या Display ) पर भरोसा नहीं करना चाहते हैं, और इसके बजाय अपना खुद का चाहते हैं, आप कैसे करते हैं वह? (क्षमा करें यदि यह पहले से ही कहीं लिखा हुआ था और मैंने इसे याद किया।) आपको ? -in- main पूरी तरह से उपयोग करना बंद नहीं करना पड़ेगा, है ना? यह अपना परिणाम और/या त्रुटि प्रकार और/या impl लिखने जैसा कुछ है? (यह मेरे लिए दुर्भाग्यपूर्ण लगता है यदि ? -in- main केवल एक खिलौना था, और जैसे ही आप "गंभीर होना" चाहते थे, आपको कम एर्गोनोमिक तरीकों पर वापस जाना होगा।)

@glaebhoerl यह बहुत सीधा है:

1. एक नया प्रकार बनाएँ।
2. From अपने पुराने त्रुटि प्रकार को लागू करें।
3. Debug (या Display ) लागू करें।
4. प्रकार को main के हस्ताक्षर में बदलें।

धन्यवाद!

Debug के कस्टम कार्यान्वयन लिखना मेरे लिए थोड़ा अजीब लगता है जो डिबगिंग-उन्मुख नहीं हैं , लेकिन मुझे लगता है कि यह दुनिया का अंत नहीं है।

@glaebhoerl यही कारण है कि Result impl को Debug IMO के बजाय Display का उपयोग करना चाहिए।

क्या Termination विशेषता में message , या error_message या ऐसा कुछ नामक एक अतिरिक्त विधि नहीं हो सकती है, जिसमें एक डिफ़ॉल्ट कार्यान्वयन है जो Debug / का उपयोग करता है / Display संदेश दिखाने के लिए? फिर आपको एक नया प्रकार बनाने के बजाय केवल एक विधि को लागू करना होगा।

@glaebhoerl @Thomasdezeeuw error_message विधि जैसा कुछ RFC के मूल मसौदे में था, लेकिन आम सहमति की कमी के कारण इसे हटा दिया गया। उस समय मेरी भावना यह थी कि बुनियादी सुविधा को प्राप्त करना सबसे अच्छा होगा (जरूरी नहीं कि स्थिर हो) और फिर पुनरावृति।

@zackw सहमत, मैं व्यक्तिगत रूप से बिना किसी संदेश के ठीक रहूंगा, केवल एक संख्या, त्रुटि कोड के लिए 0 और 1 कहें। लेकिन अगर हम पहले पुनरावृत्ति में संदेश प्राप्त करना चाहते हैं तो मुझे लगता है कि मैं Debug या Display पर किसी भी चीज़ की तुलना में Termination::message के पक्ष में अधिक हूं।

क्या वह message विधि String ? क्या यह Termination libcore में होने के साथ असंगत नहीं होगा?

@SimonSapin Termination वर्तमान में libstd में परिभाषित है।

हम्म, लेकिन मुझे नहीं लगता कि विशेषता में message एक विधि जोड़ना सबसे अच्छा कार्यान्वयन होगा। i32 जैसे प्रकारों के लिए विधि क्या लौटाएगी? यह कैसे तय होगा कि इस संदेश को कब छापना है? वर्तमान में Termination के लिए Result का कार्यान्वयन, report फ़ंक्शन में त्रुटि प्रिंट करता है। यह काम करता है, क्योंकि Result जानता है, कि यह एक Err है। हम कहीं एक चेक report() != 0 को एकीकृत कर सकते हैं और फिर प्रिंट कर सकते हैं, लेकिन यह सही नहीं लगता है।
अगली समस्या यह होगी कि हम Result के लिए एक मानक कार्यान्वयन प्रदान करना चाहते हैं, लेकिन संभवतः मुद्रित होने के लिए Error प्रकार को लागू करने की क्या आवश्यकता है? यह हमें वर्तमान प्रश्न Debug या Display पर वापस लाएगा।

एक और सिरदर्द जो आता है यदि आप "गंभीर" कार्यक्रम में मुख्य रूप से ? का उपयोग करना चाहते हैं, तो कुछ परिस्थितियों में, कमांड-लाइन प्रोग्राम गैर-शून्य स्थिति से बाहर निकलना चाहते हैं लेकिन _anything_ प्रिंट किए बिना ( grep -q पर विचार करें) Termination impl की आवश्यकता है जो _isn't_ एक Error है, जो कुछ भी प्रिंट नहीं करता है, जो आपको बाहर निकलने की स्थिति को नियंत्रित करने देता है ... और आपको यह तय करने की आवश्यकता है कि आप ' उस चीज़ को वापस लौटाना _after_ कमांड लाइन तर्कों को पार्स करना।

मैं ऐसा सोचता हूं:

वापस Result<T, E> ई के लिए डिबग इंप का उपयोग करना चाहिए। यह सबसे सुविधाजनक विशेषता है - यह व्यापक रूप से लागू किया गया है, और "त्वरित और गंदे आउटपुट" उपयोग के मामले के साथ-साथ यूनिट परीक्षण उपयोग मामले को भी संतुष्ट करता है। मैं Display दोनों का उपयोग नहीं करना पसंद करूंगा क्योंकि यह कम व्यापक रूप से लागू किया गया है और क्योंकि इससे यह आभास होता है कि यह पॉलिश आउटपुट है, जो मुझे लगता है कि अत्यधिक संभावना नहीं है।

लेकिन पेशेवर दिखने वाले आउटपुट प्राप्त करने का एक तरीका भी होना चाहिए। सौभाग्य से, पहले से ही ऐसे दो तरीके हैं। सबसे पहले, जैसा कि @withboats ने कहा, लोग "डिस्प्ले-फ्रॉम-डीबग" ब्रिज बना सकते हैं यदि वे E: Display का उपयोग करना चाहते हैं या अन्यथा पेशेवर स्टाइल आउटपुट देना चाहते हैं। लेकिन अगर यह बहुत हैकी लगता है, तो आप परिणाम को बदलने के लिए अपना खुद का प्रकार भी परिभाषित कर सकते हैं। उदाहरण के लिए, आप कर सकते हैं:

fn main() -> ProfessionalLookingResult {
    ...
}

और फिर Try के लिए ProfessionalLookingResult लागू करें। फिर आप Terminate को भी लागू कर सकते हैं, जो भी हो:

impl Terminate for ProfessionalLookingResult {
    fn report(self) -> i32 {
        ...
        eprintln!("Something very professional here.");
        return 1;
        ...
    }
}

मैं @nikomatsakis से सहमत हूं कि इसे Debug का उपयोग करना चाहिए।

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

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

मैं कुछ विचारों को संक्षेप में बताता हूं, हालांकि उनके साथ कुछ समस्याएं हैं।

मुझे निम्नलिखित देखना अच्छा लगेगा

fn main() -> i32 {
    1
}

जिसे आम तौर पर इस प्रकार लिखा जा सकता है:

fn main() -> impl Display {
    1
}

इन दोनों मुख्य कार्यों को 0 निकास कोड और println! को 1 का Display वापस करना चाहिए।

यह निम्नलिखित के रूप में सरल होना चाहिए (मुझे लगता है)।

impl<T> Termination for T where T: Display {
    fn report(self) -> i32 {
        println!("{}", self);
        EXIT_SUCCESS
    }
}

फिर त्रुटियों के लिए हमारे पास हो सकता है:

impl<T: Termination, E: Debug> Termination for Result<T, E> { ... }

जहां कार्यान्वयन केवल "{:?}" के उपयोग के साथ RFC में समान है
एक Debug प्रारूप।

जैसा कि पहले उल्लेख किया गया है, जिन लोगों को उत्पादन पर अधिक नियंत्रण की आवश्यकता होती है, वे आसानी से कर सकते हैं
लिखो:

fn main() -> Result<i32, MyError> { ... }
impl Termination for Result<i32, MyError> { ... }

हालांकि यह हमारे वर्तमान कंपाइलर के साथ अनिर्णीत होगा, मुझे लगता है, क्योंकि यह
परस्पर विरोधी कार्यान्वयन देखेंगे ... तो हम वही करते हैं जो @nikomatsakis सुझाता है
और लिखा:

fn main() -> MyResult { ... }
impl Termination for MyResult { ... }
or, if you want something more general.
impl<T, E> Termination for MyResult<T, E> { ... }

मुझे पता है कि यह आंशिक रूप से कही गई बातों को बहाल कर रहा है, लेकिन मैंने सोचा कि मैं अपनी दृष्टि पूरी तरह से पेश करूंगा, यह दिखा रहा हूं कि रिटर्न वैल्यू प्रदर्शित करने के लिए एक और सामान्य समाधान, न केवल परिणाम। ऐसा लगता है कि इस टिप्पणी का एक बहुत बहस कर रहा है कि हम डिफ़ॉल्ट रूप से Termination के कौन से कार्यान्वयन करते हैं। साथ ही यह टिप्पणी RFC में वर्णित impl Termination for bool जैसे कार्यान्वयन के विपरीत है। मैं व्यक्तिगत रूप से सोचता हूं कि गैर-शून्य निकास कोड को विशेष रूप से Results या कस्टम प्रकारों द्वारा नियंत्रित किया जाना चाहिए जो Termination लागू करते हैं।

यह एक दिलचस्प सवाल है कि ? को Option पर मुख्य रूप से कैसे संभालना है क्योंकि उनके पास Display के लिए कार्यान्वयन नहीं है।

टीएल; डीआर: मैं Debug के साथ ठीक हूं।

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

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

$ cd foo
bash: cd: foo: No such file or directory

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

जब मैं इस तरह से सरल आउटपुट प्राप्त करने के लिए Terminate impl लिखने के बारे में सोचता हूं, तो मुझे एहसास होता है कि मुख्य विशेषता से ? आज स्थिर जंग से अलग नहीं है (लिखे गए कोड की मात्रा के संदर्भ में) ), जहां एक Result -aware "inner_main ()" अक्सर E को संभालने के लिए बनाया जाता है।

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

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

"प्राथमिक लाभार्थी क्ली एप्लिकेशन है" धारणा को धारण करते हुए, बड़ी संख्या में कंसोल ऐप हैं जो सहायता और उपयोग की जानकारी प्रदान करते हैं। उदाहरण के लिए:

$ git foo
git: 'foo' is not a git command. See 'git --help'.

The most similar command is
    log

तो कंसोल ऐप्स के लिए भी, मेरे लिए Debug के साथ जाकर "घायल समूह" की पहचान करना मुश्किल है।

और अंत में, मैं Debug impl के साथ और 6 महीने के लिए आयोजित सुविधा के मुकाबले ज्यादा खुश रहूंगा, इसलिए, स्वार्थी रूप से, वह है :)।

तो मेरी विचार प्रक्रिया सार्वजनिक रूप से रखी गई है। संक्षेप में, मुझे लगता है कि Debug Display से बेहतर और बदतर नहीं होगा, और इस तरह, डिफ़ॉल्ट कार्यान्वयन के रूप में ठीक होना चाहिए।

आप में से कई लोगों की तरह, मुझे यकीन है, मैं चाहता हूं कि एक कार्यान्वयन था जिसके बारे में मैं और अधिक उत्साहित महसूस कर रहा था - जैसे, "हां, यह वही है !!!", टीबीएच। लेकिन हो सकता है कि यह सिर्फ मेरी उम्मीदें अवास्तविक हो... हो सकता है कि एक बार हमारे पास एक समाधान हो जो failure के साथ मेरी परियोजनाओं में बॉयलरप्लेट को काटने के साथ काम करता है, तो यह मुझ पर बढ़ेगा। :)

नोट मैंने परीक्षण में टर्मिनेटियो विशेषता का समर्थन करने के लिए एक पीआर खोला: #48143 ( @bkchr के काम पर निर्माण)।

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

Termination का नाम बदलकर Terminate कर दिया जाना चाहिए क्योंकि libstd में लक्षणों के लिए क्रियाओं के लिए हमारी सामान्य वरीयता के बाद।

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

अनावश्यक बाइक शेडिंग: यह एक एकल-विधि विशेषता है। अगर हम उन्हें वही नाम देना चाहते हैं, तो शायद ToExitCode / to_exit_code ?

Result को स्थिर करना विशेषता को स्थिर करने से स्वतंत्र रूप से किया जा सकता है, है ना?

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

हां, हमें विशेषता को स्थिर करने की आवश्यकता नहीं है - हालांकि यह ढांचे जैसी चीजों के लिए स्थिर पर उपयोगी है, जो जरूरी नहीं कि inner_main पर इतना भरोसा कर सके।

@SimonSapin मैं एक प्रकार के रूपांतरण के संदर्भ में To के बारे में सोचता हूं, और ऐसा नहीं है। लेकिन हम विधि को terminate नाम दे सकते हैं (मुझे नहीं लगता कि यह प्रतिबंध कब लक्षण क्रियाओं को नाम देना है। Try एक स्पष्ट काउंटर उदाहरण है।)

मैंने प्रस्ताव दिया है कि हम fn main() -> T को स्थिर करें जहां T इकाई नहीं है। यह कई विवरण छोड़ देता है - विशेष रूप से विशेषता का नाम/स्थान/विवरण - अस्थिर, लेकिन कुछ चीजें तय की जाती हैं। यहां विवरण:

https://github.com/rust-lang/rust/issues/48453

कृपया अपनी प्रतिक्रिया दें!

terminate की तुलना में report #$0$#$ अधिक वर्णनात्मक प्रतीत होता है। हम हमेशा terminate , लेकिन report आईएनजी को छोड़ सकते हैं।

लेकिन उदाहरण के विपरीत std::process::exit यह विधि कुछ भी समाप्त नहीं करती है। यह केवल main() के वापसी मूल्य को एक निकास कोड में परिवर्तित करता है (वैकल्पिक रूप से Result::Err को stderr पर प्रिंट करने के बाद)।

Exit के लिए एक और वोट। मुझे यह पसंद है कि यह संक्षिप्त, काफी वर्णनात्मक और निकास कोड/निकास स्थिति की पारंपरिक अवधारणा के अनुरूप है।

मैं निश्चित रूप से Exit से अधिक Terminate को तरजीह दूंगा क्योंकि हम मुख्य से लौटकर इनायत से बाहर निकल रहे हैं, बजाय इसके कि हम अचानक कठिन समाप्ति के बजाय जहां कुछ वास्तव में गलत हो गया था।

मैंने परिणाम लौटाने वाले यूनिट परीक्षणों को स्थिर करने का प्रस्ताव देने के लिए https://github.com/rust-lang/rust/issues/48854 जोड़ा।

अरे, मुझे इस बारे में बात करने के लिए सही जगह मिल गई है।

सिद्धांतों में ? का उपयोग करना

वर्तमान में doctests के कार्य करने का तरीका कुछ इस प्रकार है:

• रस्टडॉक इस बात की जांच करता है कि यह fn main . घोषित करता है या नहीं
  
  
  
  • (वर्तमान में यह केवल "fn main" के लिए एक पंक्ति-दर-पंक्ति पाठ खोज करता है जो // के बाद नहीं है)
  
  
• अगर fn main मिला, तो यह पहले से मौजूद चीज़ों को नहीं छूएगा
• यदि fn main नहीं मिला, तो यह अधिकांश* सिद्धांत को मूल fn main() { } में लपेट देगा
  
  
  
  • *पूर्ण संस्करण: यह #![inner_attributes] और extern crate घोषणाओं को निकालेगा और उन्हें जेनरेट किए गए मुख्य फ़ंक्शन के बाहर रखेगा, लेकिन बाकी सब कुछ अंदर चला जाएगा।
  
  
• यदि doctest में कोई बाहरी क्रेट स्टेटमेंट शामिल नहीं है (और जिस क्रेट को प्रलेखित किया जा रहा है उसे std नहीं कहा जाता है) तो रस्टडॉक जेनरेट किए गए मुख्य फ़ंक्शन से ठीक पहले extern crate my_crate; स्टेटमेंट भी सम्मिलित करेगा।
• रस्टडॉक तब परीक्षण हार्नेस के हिस्से के रूप में अंतिम परिणाम को एक स्टैंडअलोन बाइनरी के रूप में संकलित करता है और चलाता है।

(मैंने कुछ विवरण छोड़े हैं, लेकिन मैंने आसानी से यहां एक पूर्ण लेखन किया है।)

इसलिए, एक सिद्धांत में ? को मूल रूप से उपयोग करने के लिए, जिस बिट को बदलने की आवश्यकता है वह वह हिस्सा है जहां यह fn main() { your_code_here(); } जोड़ता है अपने स्वयं के fn main() -> Result<(), Error> $ की घोषणा करना जितनी जल्दी हो सके काम करेगा कि नियमित कोड में - rustdoc को वहां संशोधित करने की भी आवश्यकता नहीं है। हालाँकि, इसे मैन्युअल रूप से मुख्य घोषित किए बिना काम करने के लिए एक छोटे से ट्वीक की आवश्यकता होगी। इस सुविधा का बारीकी से पालन नहीं करने के बाद, मुझे यकीन नहीं है कि एक आकार-फिट-सभी समाधान है या नहीं। क्या fn main() -> impl Termination संभव है?

क्या fn main() -> impl टर्मिनेशन संभव है?

एक छोटे से अर्थ में, हाँ: https://play.rust-lang.org/?gist=8e353379f77a546d152c9113414a88f7&version=nightly

दुर्भाग्य से, मुझे लगता है कि -> impl Trait अंतर्निहित त्रुटि-रूपांतरण के कारण ? के साथ मौलिक रूप से परेशानी है, जिसे यह बताने के लिए अनुमान संदर्भ की आवश्यकता है कि किस प्रकार का उपयोग करना है: https://play.rust- lang.org/?gist=23410fa4fa684710bc75e16f0714ec4b&version=nightly

व्यक्तिगत रूप से मैं कल्पना कर रहा था कि ? -in-doctests https://github.com/rust-lang/rfcs/pull/2107 जैसे fn main() -> Result<(), Box<Debug>> catch { your_code_here(); } (https:// से सिंटैक्स का उपयोग करके) के माध्यम से काम कर रहे हैं। github.com/rust-lang/rust/issues/41414#issuecomment-373985777)।

impl Trait संस्करण अच्छा है, हालांकि, और काम कर सकता है अगर किसी प्रकार का "अनियंत्रित होने पर उसी प्रकार को पसंद करें" समर्थन जो कि rustc ? desugar में आंतरिक रूप से उपयोग कर सकता है, लेकिन मेरी याद है कि इस तरह की सुविधा का विचार उन लोगों को बनाता है जो समझते हैं कि चीजें कैसे डरावनी काम करती हैं: पसीना_स्माइल: लेकिन शायद यह एक आंतरिक चीज है जो केवल तभी लागू होती है जब आउटपुट impl Trait संभव होगा ...

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

मुझे आश्चर्य है कि केवल एक चीज यह है कि यह संस्करण संक्रमण से कैसे प्रभावित होगा। क्या 2018 के युग में catch सिंटैक्स नहीं बदल रहा है? Rustdoc संभवतः उसी संस्करण में सिद्धांतों को संकलित करना चाहेगा जिस पुस्तकालय में वह चल रहा है, इसलिए इसे युग ध्वज के आधार पर सिंटैक्स के बीच अंतर करने की आवश्यकता होगी।

मुझे चिंता है कि यह अब स्थिर हो गया है लेकिन साधारण मामले स्पष्ट रूप से अभी भी ICE: https://github.com/rust-lang/rust/issues/48890#issuecomment -375952342

fn main() -> Result<(), &'static str> {
    Err("An error message for you")
}

assertion failed: !substs.has_erasable_regions(), librustc_trans_utils/symbol_names.rs:169:9

https://play.rust-lang.org/?gist=fe6ae28c67e7d3195a3731839d4aac84&version=nightly

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

@frewsxcv मुझे लगता है कि समस्याएं अब ठीक हो गई हैं, है ना?

@nikomatsakis मैंने https://github.com/rust-lang/rust/issues/48389 में जो मुद्दा उठाया था, उसे 1.26-बीटा में हल किया गया है, इसलिए हां मेरे दृष्टिकोण से।

हाँ, मैं जिस ICE को लेकर चिंतित था वह अब ठीक हो गया है!

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

TL; DR - मुझे लगता है कि त्रुटि का Debug संदेश दिखाना एक गलती थी, और यह कि एक त्रुटि के Display संदेश का उपयोग करना एक बेहतर विकल्प होगा।

मेरे विश्वास के मूल में यह है कि, जो कोई _रूस्ट_ में _नियमित रूप से सीएलआई प्रोग्राम बनाता है, मुझे कभी भी इस बारे में अधिक ध्यान देने की याद नहीं आती कि $#$ Error $#$ का Debug संदेश क्या है। अर्थात्, त्रुटि का Debug डिज़ाइन द्वारा, डेवलपर्स के लिए है, न कि अंतिम उपयोगकर्ताओं के लिए। जब आप एक सीएलआई प्रोग्राम बनाते हैं, तो इसका इंटरफ़ेस मूल रूप से अंतिम उपयोगकर्ताओं द्वारा पढ़ने के लिए होता है, इसलिए Debug संदेश की यहां बहुत कम उपयोगिता है। यही है, अगर मैंने अंतिम उपयोगकर्ताओं को भेजे गए किसी भी सीएलआई प्रोग्राम को सामान्य ऑपरेशन में जंग मान का डीबग प्रतिनिधित्व दिखाया है, तो मैं एक बग को ठीक करने पर विचार करूंगा। मुझे आम तौर पर लगता है कि यह रस्ट में लिखे गए प्रत्येक सीएलआई कार्यक्रम के लिए सही होना चाहिए, हालांकि मैं समझता हूं कि यह एक ऐसा बिंदु हो सकता है जिस पर उचित लोग असहमत हो सकते हैं। इसके साथ ही, मेरी राय का कुछ चौंकाने वाला निहितार्थ यह है कि हमने एक ऐसी सुविधा को प्रभावी ढंग से स्थिर कर दिया है जहां इसके संचालन का डिफ़ॉल्ट मोड आपको एक बग (फिर से, आईएमओ) से शुरू करता है जिसे ठीक किया जाना चाहिए।

डिफ़ॉल्ट रूप से Debug त्रुटि का प्रतिनिधित्व दिखाकर, मुझे यह भी लगता है कि हम खराब अभ्यास को प्रोत्साहित कर रहे हैं। विशेष रूप से, रस्ट सीएलआई कार्यक्रम लिखने के दौरान यह देखना बहुत आम है कि त्रुटि का Display भी अंत उपयोगकर्ताओं द्वारा उपभोग करने के लिए पर्याप्त नहीं है, और यह वास्तविक कार्य किया जाना चाहिए इसे ठीक करें। इसका एक ठोस उदाहरण है io::Error । एक संबंधित फ़ाइल पथ के बिना io::Error दिखाना (यह मानते हुए कि यह फ़ाइल पढ़ने/लिखने/खोलने/बनाने से आया है) मूल रूप से एक बग है, क्योंकि अंतिम उपयोगकर्ता के लिए इसके साथ कुछ भी करना मुश्किल है। डिफ़ॉल्ट रूप से Debug त्रुटि के प्रतिनिधित्व को दिखाने का चुनाव करके, हमने सीएलआई प्रोग्राम बनाने वाले लोगों द्वारा उन प्रकार की बगों को उजागर करना कठिन बना दिया है। (इसके ऊपर, Debug का io::Error अपने Display की तुलना में बहुत कम उपयोगी है, लेकिन यह अपने आप में मेरे अनुभव में एक बड़ा दर्द बिंदु नहीं है। )

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

use std::error::Error;
use std::process;

fn try_main() -> Result<(), Box<Error>> {
    // do stuff with `?`
}

fn main() {
    if let Err(err) = try_main() {
        eprintln!("{}", err);
        process::exit(1);
    }
}

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

"एक त्रुटि संदेश उत्सर्जित करें और एक उपयुक्त त्रुटि कोड के साथ बाहर निकलें" का पैटर्न वास्तव में पॉलिश किए गए कार्यक्रमों में उपयोग किया जाता है। उदाहरण के लिए, यदि ?-in-main ने Display का उपयोग किया है, तो मैं आज ripgrep में main और run फ़ंक्शंस को मर्ज कर सकता हूं:

https://github.com/BurntSushi/ripgrep/blob/64317bda9f497d66bbeffa71ae6328601167a5bd/src/main.rs#L56 -L86

बेशक, मैं भविष्य में ?-in-main Termination विशेषता के लिए अपना खुद का इम्प्लांट प्रदान करके कर सकता हूं जो एक बार स्थिर हो जाता है, लेकिन अगर मैं सिर्फ main लिख सकता हूं तो मुझे ऐसा करने में परेशानी क्यों होगी मेरे पास impl को शामिल करना होगा ताकि वे वास्तविकता से मेल खा सकें, और उस बिंदु पर, मैं आज के उदाहरणों के साथ भी रह सकता हूं ( main का उपयोग करके और एक try_main )।

देखने से ऐसा लगता है कि इसे ठीक करना एक ब्रेकिंग बदलाव होगा। यही है, यह कोड आज जंग स्थिर पर संकलित करता है:

#[derive(Debug)]
struct OnlyDebug;

fn main() -> Result<(), OnlyDebug> {
    Err(OnlyDebug)
}

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

मैं सहमत हूं कि Display को Debug $ से अधिक प्रदर्शित करना सीएलआई अनुप्रयोगों के लिए बेहतर है। मैं इस बात से सहमत नहीं हूं कि यह Debug के बजाय Debug Display होना चाहिए, क्योंकि यह वास्तव में ? -ed त्रुटियों को सीमित करता है और ?-in-main के उद्देश्य को हरा देता है Display का उपयोग करने के लिए एक गैर-ब्रेकिंग तरीका प्रदान करेगा और जब यह नहीं होगा तो Debug पर वापस आ जाएगा।

#[unstable(feature = "termination_trait_lib", issue = "43301")]
impl<E: fmt::Display> Termination for Result<!, E> {
    fn report(self) -> i32 {
        let Err(err) = self;
        eprintln!("Error: {}", err);
        ExitCode::FAILURE.report()
    }
}

अंत में, अपने तर्क को समाप्त करने के लिए, मुझे उन परिस्थितियों की कल्पना करने में भी कठिनाई होती है जिनके तहत मैं उदाहरणों में भी ?-in-main का उपयोग करूंगा।

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

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

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

यदि हम Display का उपयोग करते हैं, तो हम कई प्रकार की त्रुटियों को जमा करने के लिए MainError जैसे तेज़ और गंदे प्रकार का परिचय दे सकते हैं:

pub struct MainError {
    s: String,
}

impl std::fmt::Display for MainError {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        self.s.fmt(f)
    }
}

impl<T> From<T> for MainError where T: std::error::Error {
    fn from(t: T) -> Self {
        MainError {
            s: t.to_string(),
        }
    }
}

यह Box<Error> के समान नीचे की तरह कुछ की अनुमति देगा:

fn main() -> Result<(), MainError> {
    let _ = std::fs::File::open("foo")?;
    Ok(())
}

डिस्प्ले बनाम डीबग की पिछली चर्चा यहां छिपे हुए हिस्से में है, जो https://github.com/rust-lang/rust/issues/43301#issuecomment -362020946 के आसपास शुरू हो रही है।

@ बर्नटसुशी मैं आपसे सहमत हूं। यदि इसे ठीक नहीं किया जा सकता है, तो एक समाधान हो सकता है:

use std::fmt;
struct DisplayAsDebug<T: fmt::Display>(pub T);

impl<T: fmt::Display> Debug for DisplayAsDebug {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        fmt::Display::fmt(&self.0, f)
    }
}

impl<T: fmt::Display> From<T> for DisplayAsDebug {
    fn from(val: T) -> Self {
        DisplayAsDebug(val)
    }
}

अगर यह std::fmt में होता, तो हम कुछ इस तरह इस्तेमाल कर सकते थे:

use std::{fmt, io};

fn main() -> Result<(), fmt::DisplayAsDebug<io::Error>> {
    let mut file = File::open("/some/file")?;
    // do something with file
}

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

मुझे लगता है कि इसे पीछे की ओर असंगत तरीके से ठीक करना ठीक है यदि यह जल्द ही किया जाता है, इससे पहले कि बहुत अधिक कोड स्थिर पर इसका उपयोग कर रहा हो।

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

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

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

यदि हम Display का उपयोग करते हैं, तो हम कई प्रकार की त्रुटियों को जमा करने के लिए MainError जैसे तेज़ और गंदे प्रकार का परिचय दे सकते हैं:

व्यक्तिगत रूप से, इस प्रकार का समाधान पर्याप्त जटिलता जोड़ देगा कि ? -in- main पूरी तरह से बचना आसान है।

@Aaronepower :

जहां तक ​​​​मैं कह सकता हूं (पूरी तरह से गलत हो सकता है क्योंकि मेरे पास stdlib को संकलित करने का समय नहीं है और मुझे नहीं पता कि विशेषज्ञता इसमें शामिल है या नहीं) कोई कारण नहीं है कि हम टर्मिनेशन के लिए निम्नलिखित इम्प्लांट नहीं जोड़ सकते हैं। यह उपलब्ध होने पर डिस्प्ले का उपयोग करने के लिए एक गैर-ब्रेकिंग तरीका प्रदान करेगा और ऐसा नहीं होने पर डीबग पर वापस आ जाएगा।

अगर यह मुझे fn main() -> Result<(), failure::Error> लिखने और Display का उपयोग करके एक अच्छी, मानव-पठनीय त्रुटि प्राप्त करने में सक्षम बनाता है, तो यह निश्चित रूप से मेरी प्रमुख चिंताओं को पूरा करेगा। हालांकि, मुझे लगता है कि यह अभी भी वैकल्पिक रूप से बैकट्रेस को failure::Error में प्रदर्शित करने के सवाल को छोड़ देगा जब RUST_BACKTRACE=1 सेट हो - लेकिन यह दायरे से बाहर हो सकता है, वैसे भी, या कम से कम एक मुद्दा जो होना चाहिए failure के साथ लिया जाए।

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

उदाहरण के लिए, आप त्रुटि प्रकार के लिए अपना "आवरण" परिभाषित कर सकते हैं, और इसके लिए From लागू कर सकते हैं:

struct PrettyPrintedError { ... }
impl<E: Display> From<E> for PrettyPrintedError { }

impl Debug { /* .. invoke Display .. */ }

अब आप कुछ इस तरह लिख सकते हैं, जिसका मतलब है कि आप ? में main का उपयोग कर सकते हैं:

fn main() -> Result<(), PrettyPrintedError> { ... }

शायद इस तरह का एक त्वरित-क्ली या कुछ का हिस्सा होना चाहिए?

@nikomatsakis हाँ, मुझे पूरी तरह से वह समाधान मिल गया है, लेकिन मुझे ऐसा लगता है कि ?-in-main का उपयोग करने की संक्षिप्तता के उद्देश्य को हरा देता है। मुझे ऐसा लगता है कि "इस वर्कअराउंड का उपयोग करके ?-in-main का उपयोग करना संभव है" दुर्भाग्य से ?-in-main को कमजोर करता है। उदाहरण के लिए, मैं आपके काम के बारे में संक्षिप्त उदाहरणों में नहीं लिखने जा रहा हूँ और मैं प्रत्येक उदाहरण के लिए quicli पर निर्भरता नहीं थोपने जा रहा हूँ। मैं निश्चित रूप से त्वरित कार्यक्रमों के लिए इसका उपयोग नहीं करने जा रहा हूं, क्योंकि मैं मूल रूप से मेरे द्वारा लिखे गए प्रत्येक सीएलआई प्रोग्राम में एक त्रुटि का Display आउटपुट चाहता हूं। मेरी राय है कि त्रुटि का डिबग आउटपुट सीएलआई कार्यक्रमों में एक बग है जिसे आप उपयोगकर्ताओं के सामने रखते हैं।

?-in-main का विकल्प एक अतिरिक्त ~4-लाइन फ़ंक्शन है। इसलिए यदि ?-in-main का उपयोग करने के लिए Display को ठीक करने का समाधान उससे कहीं अधिक है, तो मुझे व्यक्तिगत रूप से इसका उपयोग करने के लिए बहुत अधिक कारण नहीं दिखता है (डॉक्टर परीक्षणों या यूनिट परीक्षणों के बाहर, जैसा कि उपर्युक्त)।

क्या यह कुछ ऐसा है जिसे संस्करण में बदला जा सकता है?

@BurntSushi आप std में होने वाले कामकाज के बारे में कैसा महसूस करेंगे, इसलिए आपको main() पर केवल थोड़ी देर वापसी प्रकार की घोषणा लिखनी होगी?

@Kixunil मेरी प्रारंभिक भावना यह है कि यह स्वादिष्ट हो सकता है। हालांकि इस पर ज्यादा विचार नहीं किया।

@बर्नटसुशी

?-in-main का विकल्प एक अतिरिक्त ~4-लाइन फ़ंक्शन है।

अंततः, व्यवहार स्थिर है, और मुझे नहीं लगता कि हम इस बिंदु पर इसे वास्तविक रूप से बदल सकते हैं। (मेरा मतलब है कि यह एक सुदृढ़ता उल्लंघन या कुछ और नहीं है।)

उस ने कहा, मुझे अभी भी वर्तमान सेटअप बहुत अच्छा और बेहतर लगता है Display , लेकिन मुझे लगता है कि यह एक बात है कि आप "डिफ़ॉल्ट" क्या चाहते हैं - यानी, या तो सेटअप को काम करने के लिए बनाया जा सकता है अन्य विभिन्न newtypes के माध्यम से। इसलिए या तो हम डिफ़ॉल्ट रूप से "क्विक-एन-डर्टी" स्क्रिप्ट्स को पसंद करते हैं, जो Debug चाहते हैं, या पॉलिश्ड एंड प्रोडक्ट्स चाहते हैं। मुझे लगता है कि एक पॉलिश अंत उत्पाद वह है जहां मैं एक अतिरिक्त आयात आसानी से कर सकता हूं, और जहां मैं कई अलग-अलग संभावित प्रारूपों से चुनना चाहता हूं (उदाहरण के लिए, क्या मुझे केवल त्रुटि चाहिए, या क्या मैं argv शामिल करना चाहता हूं [0], आदि)।

अधिक ठोस होने के लिए, मुझे लगता है कि यह इस तरह दिखेगा:

use failure::format::JustError;

fn main() -> Result<(), JustError> { .. }

या, एक अलग प्रारूप प्राप्त करने के लिए, शायद मैं यह करता हूं:

use failure::format::ProgramNameAndError;

fn main() -> Result<(), ProgramNameAndError> { .. }

आपके द्वारा पहले लिखे गए 4-लाइन फ़ंक्शन की तुलना में ये दोनों काफी अच्छे लगते हैं:

use std::sys;

fn main() {
  match inner_main() {
    Ok(()) => { }
    Err(error) => {
      println!("{}", error);
      sys::exit(1);
    }
}

fn inner_main() -> Result<(), Error> {
  ...
}

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

@nikomatsakis शायद यह एक बेहतर दीर्घकालिक दृष्टिकोण है, और मुझे आपका अंतिम परिणाम स्वादिष्ट लगता है। यह अच्छा होगा यदि वे त्रुटि प्रकार किसी दिन std में समाप्त हो जाएं ताकि उनका उपयोग यथासंभव कम ओवरहेड वाले उदाहरणों में किया जा सके। :-)

प्रक्रिया नोट: मैंने अपनी प्रारंभिक प्रतिक्रिया को यहां "क्या कुछ भी किया जा सकता है" के बजाय "चलो कुछ ऐसा बदल दिया है जो पहले से ही स्थिर हो गया है" के साथ तैयार करने की कोशिश की, उच्च स्तर के लक्ष्य पर ध्यान केंद्रित करने के बजाय हम कुछ मांगते हैं निश्चित रूप से नहीं कर सकता। :-)

खैर इसमें ज्यादा समय नहीं लगा: https://crates.io/crates/exitfailure

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

@WiSaGaN RFC का विवरण समय-समय पर बदल सकता है और बदल सकता है। यह अपेक्षित और स्वस्थ है। RFC डिज़ाइन दस्तावेज़ हैं और जो है और हमेशा रहेगा उसका सही प्रतिनिधित्व नहीं है। सूचना की खोज कठिन है, और अधिक ध्यान न देने के लिए यह मेरी गलती है। मैं उम्मीद कर रहा हूं कि हम इस सुविधा की स्थिरता को कम करने से बच सकते हैं और इसके बजाय उच्च स्तर के लक्ष्यों पर ध्यान केंद्रित कर सकते हैं जिन पर हम व्यावहारिक रूप से कार्य कर सकते हैं।

@nikomatsakis त्वरित-एन-गंदे मामलों के पक्ष में मुख्य मुद्दा यह है कि उन्हें संबोधित करने का एक तरीका पहले से ही है: .unwrap() । तो उस दृष्टिकोण से, ? त्वरित-गंदी चीजें लिखने का एक और तरीका है, फिर भी पॉलिश चीजों को लिखने का कोई आसान तरीका नहीं है।

बेशक जहाज रवाना हो गया है, इसलिए हम ज्यादातर खराब हो गए हैं। यदि संभव हो तो मुझे अगले संस्करण में इसे बदलते हुए देखना अच्छा लगेगा।

@Kixunil , unwrap वास्तव में चीजों को संबोधित करने का एक अच्छा तरीका नहीं है, क्योंकि इस धागे के शीर्षक में कहा गया है कि हम $# main #$ में वाक्यात्मक चीनी ? का उपयोग करने में सक्षम होना चाहते हैं। . मैं समझ सकता हूं कि आप कहां से आ रहे हैं (वास्तव में यह विकल्प प्रबंधन के लिए ? के उपयोग के साथ मेरी प्रारंभिक झिझक का हिस्सा था) लेकिन भाषा में ? को शामिल करने के साथ यह मुद्दा एक है बहुत अच्छी उपयोगिता IMHO जीतें। यदि आपको अच्छे आउटपुट की आवश्यकता है, तो आपके लिए विकल्प हैं। आप पहले परीक्षण किए बिना उपयोगकर्ताओं को चीजें जारी नहीं करते हैं, और यह पता लगाना कि आपको main के आउटपुट के लिए एक कस्टम प्रकार की आवश्यकता है, एक बहुत ही त्वरित अहसास होगा।

जहां तक ​​"क्यों" की बात है तो हम ? में main चाहते हैं, अच्छी तरह से विचार करें कि यह अब कितना अजीब है। आप इसे व्यावहारिक रूप से हर जगह उपयोग कर सकते हैं (चूंकि आपके पास रिटर्न प्रकार का नियंत्रण है)। main फ़ंक्शन तब थोड़े विशेष महसूस करता है, जो इसे नहीं करना चाहिए।

.unwrap() एक त्वरित और गंदा समाधान है जो रचना नहीं करता है, इसलिए जब आप किसी प्रोग्राम को स्केच कर रहे हों तो आप main() के अंदर और बाहर कोड का कारक नहीं बना सकते हैं।

तुलना करके, ? एक त्वरित और गंदा समाधान है जो रचना करता है , और इसे जल्दी-और-गंदा नहीं बनाना main() पर सही रिटर्न-प्रकार डालने का मामला है, नहीं कोड को ही संशोधित करने का।

@ स्क्रूटापेलो आह, अब यह मुझे समझ में आता है। धन्यवाद!

मैं केवल यह व्यक्त करना चाहता हूं कि मैंने सोचा था कि इसका उद्देश्य अतिरिक्त रैपरों का सहारा लिए बिना सभी अनुप्रयोगों के लिए ? में main लाना था ... यदि यह केवल परीक्षण के लिए है तो मैं नहीं इसमें बहुत लाभ देखें और दुख की बात है कि .unwrap() से चिपके रहेंगे।

@oblitum यह सिर्फ परीक्षण के लिए नहीं है। यह सिर्फ (डिफ़ॉल्ट रूप से) Display प्रारूप का उपयोग करने वाला नहीं है। यह वह आउटपुट हो भी सकता है और नहीं भी जिसकी आप तलाश कर रहे हैं, लेकिन यह लगभग निश्चित रूप से .unwrap के आउटपुट से बेहतर होगा। इसके साथ ही, यह आपके कोड को ? का उपयोग करने के लिए "अच्छा" बना सकता है। किसी भी मामले में ? main अनुकूलित करना अभी भी संभव है जैसा कि @nikomatsakis ने ऊपर विस्तार से बताया है।

क्या डिस्प्ले केस के लिए stdlib में एक नया प्रकार पेश करना संभव होगा? कुछ इस तरह:

#[derive(Clone, Copy, PartialEq, PartialOrd, Eq, Ord, Debug, Hash)]
#[must_use]
struct DisplayResult<E: fmt::Display>(Result<(), E>)

impl<E> Termination for DisplayResult<E> {
    // ... same as Result, but use "{}" instead of "{:?}"
}

impl<E> From<Result<(), E>> for DisplayResult<E> {}
impl<E> Deref<Result<(), E>> for DisplayResult<E> {}
impl<E> Try for DisplayResult<E> {}
// ...

इससे उपयोगकर्ताओं को लिखने की अनुमति मिलनी चाहिए:

fn main() -> DisplayResult<MyError> {
    // Ordinary code; conversions happen automatically via From, Try, etc.
}

यहाँ मुख्य प्रेरणाएँ हैं:

• त्रुटि वापस आने पर डिस्प्ले का उपयोग किया जाता है
• उपयोगकर्ताओं को अपनी त्रुटि या परिणाम प्रकारों की कोई अतिरिक्त रैपिंग करने की आवश्यकता नहीं है; वे अपने मुख्य कार्य में केवल ? का उपयोग कर सकते हैं।

फॉलो-अप: मेरे साथ ऐसा होता है कि ? और From के शब्दार्थ इस तरह से काम करने की अनुमति नहीं दे सकते हैं जैसा मैं चाहूंगा। मुझे पता है कि ? त्रुटि प्रकारों के बीच From के माध्यम से परिवर्तित हो जाएगा, लेकिन मुझे नहीं पता कि यह Try के विभिन्न कार्यान्वयनकर्ताओं के लिए एक ही काम करता है या नहीं। यानी यह Result<?, io::Error> से Result<?, FromIoError> में बदल जाएगा, लेकिन जरूरी नहीं कि Result<?, Err> से DisplayResult<Result<?, Err>> हो। असल में, मैं काम करने के लिए इस तरह कुछ ढूंढ रहा हूं:

fn main() -> DisplayResult<io::Error> {
    let f = io::File::open("path_to_file")?;
    let result = String::new();
    f.read_to_string(result)?
}

यह मानते हुए कि यह काम नहीं करता है, शायद इसके बजाय इसे Cargo.toml में एक साधारण सशर्त संकलन ध्वज बनाया जा सकता है?

@Lucretiel : आपको लगता है कि प्रोग्रामर मुख्य रूप से कंसोल पर एक निकास संदेश प्रिंट करना चाहते हैं। यह गैर-तकनीकी डेस्कटॉप अनुप्रयोगों, लॉगिंग प्लंबिंग के साथ डेमॉन आदि के लिए मान्य नहीं है। मैं चाहता हूं कि हम मानक पुस्तकालय में 'सामान्य रूप से उपयोगी' सामग्री को बिना सम्मोहक साक्ष्य (जैसे संख्या) के बिना न जोड़ें, यह वहां होना चाहिए।

मुझे लगता है कि प्रोग्रामर जो Result<(), E> where E: Error से main वापस कर रहे हैं, कंसोल पर एक त्रुटि संदेश प्रिंट करने में रुचि रखते हैं, हां। यहां तक ​​​​कि वर्तमान व्यवहार, जो Debug के माध्यम से प्रिंट है, "कंसोल पर एक निकास संदेश प्रिंट करें" है।

इस सूत्र में व्यापक सहमति प्रतीत होती है कि कुछ को stderr पर मुद्रित किया जाना चाहिए; किए जाने वाले प्रमुख निर्णय हैं "क्या इसे "{}" या "{:?}" , या कुछ और के साथ प्रिंट करना चाहिए, और यह कितना विन्यास योग्य होना चाहिए, यदि बिल्कुल भी"।

@Lucretiel , मेरे लिए Result लौटने का मूल्य बाहर निकलने की स्थिति को अच्छी तरह से नियंत्रित कर रहा है। क्या कुछ प्रिंट करना सबसे अच्छा नहीं है जो पैनिक हैंडलर पर छोड़ दिया जाए? केवल यह सवाल नहीं है कि क्या कुछ को stderr पर प्रिंट करना है, यह भी कि क्या प्रिंट करना है (बैकट्रेस, त्रुटि संदेश, आदि?) देखें https://github.com/rust-lang/rust/issues/43301#issuecomment -389099936, esp। अंतिम भाग।

मैंने हाल ही में इसका इस्तेमाल किया और कामना की कि इसे Display कहा जाए। बहुत यकीन है कि हमने यहां गलत कॉल किया है।

एक प्रक्रिया विफलता जो मैंने नोटिस की है वह यह है कि निर्णय लैंग टीम (मुख्य रूप से निको और आई) द्वारा किया गया था, न कि libs टीम, लेकिन प्रश्न में कोड पूरी तरह से एसटीडी में रहता है। संभवतः libs ने बेहतर निर्णय लिया होगा।

@withboats क्या बदलने में बहुत देर हो चुकी है? मैंने देखा है कि दस्तावेज़ में सुविधा को अभी भी केवल रात्रिकालीन/प्रयोगात्मक के रूप में टैग किया गया है, लेकिन यह संभव है कि मैं स्थिरीकरण प्रक्रिया के पीछे की कुछ बारीकियों को नहीं समझता।

जब टीम ने मुझे कार्यान्वयन को Display से Debug में बदलने के लिए कहा तो मैं भी इस बदलाव को देखना चाहता हूं और इसके लिए एक मजबूत वकील नहीं होने का खेद है।

@Lucretiel Termination विशेषता रात्रिकालीन है, लेकिन सुविधा ही ( Termination कार्यान्वयन main /tests से लौटा रही है) पहले से ही स्थिर है।

क्या विशेषता के नाम को स्थिर करने के लिए कोई टिकट या समयरेखा है?

@xfix इसका मतलब यह होगा कि कार्यान्वयन को बदलना संभव है, है ना? व्यवहार नहीं बदलता है ( Termination main से लौटाया गया), लेकिन विशेषता स्वयं से बदल जाएगी:

impl<E: Debug> Termination for Result<(), E> ...

प्रति:

impl<E: Display> Termination for Result<(), E> ...

कार्यान्वयन को बदलना संभव है, है ना?

पीछे की संगतता को तोड़े बिना नहीं। यह कोड आज के स्थिर रस्ट में संकलित करता है:

#[derive(Debug)]
struct X;

fn main() -> Result<(), X> {
    Ok(())
}

Display की आवश्यकता के प्रस्तावित परिवर्तन के साथ, यह संकलन बंद कर देगा।

जैसा कि पहले ही उल्लेख किया जा चुका है, यह संभव है कि विशेषज्ञता की तरह कुछ मदद कर सकता है, लेकिन विशेषज्ञता की मेरी वर्तमान समझ यह है कि यह केवल उन प्रकारों के लिए उपयोगी होगा जो Display और Debug दोनों को लागू करते हैं (यानी ऐसा है कि वहां है एक कार्यान्वयन जो अधिक विशेष है)।

trait ResultTerm {
    fn which(&self);
}
impl<T: Debug> ResultTerm for T {
    default fn which(&self) {
        println!("{:?}", self)
    }
}
impl<T: Debug + Display> ResultTerm for T {
    fn which(&self) {
        println!("{}", self)
    }
}

enum MyResult<T, E> {
    Ok(T),
    Err(E),
}

impl<T, E> Termination for MyResult<T, E>
where
    E: ResultTerm,
{
    fn report(self) -> i32 {
        match self {
            MyResult::Err(e) => {
                e.which();
                1
            }
            _ => 0,
        }
    }
}

खेल का मैदान

यह सभी सामान्य मामलों को कवर करने के लिए पर्याप्त हो सकता है, लेकिन यह सार्वजनिक रूप से विशेषज्ञता को उजागर करता है।

आह, मैं देखता हूं कि स्थिर जंग के बारे में आपका क्या मतलब है। किसी कारण से मुझे पता नहीं था कि यह स्थिर में उपलब्ध था।

क्या यह ऐसा कुछ है जिसे कार्गो ध्वज के साथ संकलन समय पर स्विच किया जा सकता है? उसी तरह जैसे अन्य चीजें स्विच करने योग्य हैं, जैसे panic = "abort" ।

शायद? मैं देख सकता था कि एक अन्य जंग संस्करण में ? में main के लिए एक अलग व्यवहार करना संभव है। शायद 2018 नहीं, शायद 2021?

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

मुझे नहीं लगता कि हमें कुछ भी कम करने की जरूरत है। मैं @Aaronepower की भावना को प्रतिध्वनित करूंगा कि केवल प्रदर्शन प्रकारों को सीमित करने से केवल त्वरित-स्क्रिप्ट उपयोगकर्ताओं को असंतुष्ट किया जा सकता है (डीबग प्राप्त करना तुच्छ है, प्रदर्शन को लागू करना नहीं है) उसी तरह जैसे कि वर्तमान स्थिति उत्पादन उपयोगकर्ताओं को असंतुष्ट करती है। यहां तक ​​कि अगर हम कर सकते हैं, तो मुझे नहीं लगता कि यह अंततः एक लाभ होगा। मुझे लगता है कि @shepmaster द्वारा निर्धारित विशेषज्ञता दृष्टिकोण में वादा किया गया है, जिसमें यह निम्नलिखित व्यवहार बनाएगा:

1. एक प्रकार जिसमें डीबग है लेकिन डिस्प्ले नहीं है, उसका डीबग आउटपुट डिफ़ॉल्ट रूप से मुद्रित होगा
2. एक प्रकार जिसमें डीबग और डिस्प्ले दोनों होते हैं, उसका डिस्प्ले आउटपुट डिफ़ॉल्ट रूप से मुद्रित होगा
3. एक प्रकार जिसमें डिस्प्ले है लेकिन डिबग नहीं है, एक कंपाइलर त्रुटि का परिणाम है

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

बिंदु 3 के लिए, यह थोड़ा जानदार है (हो सकता है कि हमें 1.0 में trait Display: Debug वापस करना चाहिए था?), लेकिन अगर किसी को डिस्प्ले इम्प्लांट लिखने की परेशानी हो गई है, तो उन्हें थप्पड़ मारने के लिए कहने के लिए बहुत कुछ नहीं है एक एकल व्युत्पन्न (जो, मुझे संदेह है, उनके पास शायद वैसे भी है ... क्या वहां कोई है जो सिद्धांत पर अपने प्रदर्शन प्रकार पर डीबग करने के लिए ऑब्जेक्ट करता है?)

केवल प्रदर्शन प्रकारों तक सीमित करना त्वरित-स्क्रिप्ट उपयोगकर्ताओं को असंतुष्ट करने का काम कर सकता है (डीबग प्राप्त करना तुच्छ है, प्रदर्शन को लागू करना नहीं है)

एक मामला जहां Display Debug स्क्रिप्ट में Debug से बेहतर है, त्रुटि प्रकार के रूप में &'static str या String का उपयोग कर रहा है। यदि आपके पास #[derive(Debug)] थप्पड़ मारने के लिए एक कस्टम त्रुटि प्रकार है, तो आप पहले से ही त्रुटि प्रबंधन पर कुछ गैर तुच्छ ऊर्जा खर्च कर रहे हैं।

@SimonSapin मैं यह नहीं कहूंगा कि यह एक त्वरित स्क्रिप्टिंग वातावरण में बेहतर है, या यह बेहतर नहीं है कि मैं ऐसी स्थिति में रहूंगा जहां मैं चाहता था कि स्ट्रिंग को Display प्रारूप के रूप में मुद्रित किया जाए, बिना प्रयास किए त्रुटियों को ठीक से स्वरूपित करने के लिए, मेरे लिए Debug को प्राथमिकता दी जाती है क्योंकि स्ट्रिंग होने पर त्रुटि प्रारूप अच्छी तरह से गठित नहीं होता है, इसलिए इसके चारों ओर Err("…") होने से मैं आसानी से किसी अन्य से त्रुटि को आसानी से चुन सकता हूं आउटपुट जो उत्सर्जित हो सकता है।

FWIW जो स्वरूपित है वह Result<_, E> मान नहीं है, केवल E मान अंदर है। तो आप आउटपुट में Err( नहीं देखेंगे। हालांकि वर्तमान कोड एक Error: उपसर्ग जोड़ता है, जो संभवत: यदि Display का उपयोग किया जाता है तो वह रहेगा। उद्धरणों को प्रिंट न करने के अलावा, Display भी बैकस्लैश नहीं करेगा-स्ट्रिंग की सामग्री से बच जाएगा जो वांछनीय IMO है जब यह उपयोगकर्ताओं को एक (त्रुटि) संदेश दिखाने की बात आती है।

https://github.com/rust-lang/rust/blob/cb6eeddd4dcefa4b71bb4b6bb087d05ad8e82145/src/libstd/process.rs#L1527 -L1533

मुझे लगता है कि स्थिति को देखते हुए हम जो सबसे अच्छी चीज कर सकते हैं, वह उन प्रकारों के लिए विशेषज्ञता है जो Display impl को प्रिंट करने के लिए $# Display + Debug 0$#$ लागू करते हैं। यह दुर्भाग्यपूर्ण है कि Debug को लागू नहीं करने वाले प्रकारों को त्रुटियों के रूप में उपयोग नहीं किया जा सकता है (जब तक हम प्रतिच्छेदन impls का समर्थन नहीं करते), लेकिन यह सबसे अच्छा हम कर सकते हैं।

मुख्य प्रश्न यह है कि क्या वह इम्प्लांट एसटीडी में विशेष इम्प्लांट्स के लिए हमारी वर्तमान नीति के अंतर्गत आता है या नहीं। हमारे पास आम तौर पर एक नियम है कि हम केवल एसटीडी में विशेषज्ञता का उपयोग करते हैं जहां हम एक स्थिर गारंटी प्रदान नहीं करते हैं कि व्यवहार बाद में नहीं बदलेगा (क्योंकि विशेषज्ञता स्वयं एक अस्थिर विशेषता है)। क्या हम अब इस जागरूकता को प्रदान करने में सहज हैं कि यह संभव है कि किसी दिन ये प्रकार अपने Debug आउटपुट को प्रिंट करने के लिए वापस आ जाएंगे यदि हम अंततः एक विशेषता के रूप में विशेषज्ञता को हटा देते हैं?

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

use std::cell::Cell;
use std::fmt::*;

struct Foo<'a, 'b> {
     a: &'a Cell<&'a i32>,
     b: &'b i32,
}

impl<'a, 'b> Debug for Foo<'a, 'b> {
    fn fmt(&self, _: &mut Formatter) -> Result {
        Ok(())
    }
}

impl<'a> Display for Foo<'a, 'a> {
    fn fmt(&self, _: &mut Formatter) -> Result {
        self.a.set(self.b);
        Ok(())
    }
}

जिस तरह से विशेषज्ञता वर्तमान में काम करती है, उसके कारण मैं report को Foo<'a, 'b> $ पर कॉल कर सकता हूं जहां 'b 'a से अधिक नहीं रहता है, और यह वर्तमान में पूरी तरह से संभव है कि संकलक आजीवन आवश्यकताओं को पूरा नहीं करने के बावजूद Display इंस्टेंस में कॉल करने वाले इम्प्लांट का चयन करेगा, जिससे उपयोगकर्ता को संदर्भ के जीवनकाल को अमान्य रूप से विस्तारित करने की अनुमति मिलती है।

मैं आप लोगों के बारे में नहीं जानता, लेकिन जब मैं त्वरित "स्क्रिप्ट" लिखता हूं, तो मुझे बस unwrap() सब कुछ खत्म हो जाता है। यह 100 गुना बेहतर है, क्योंकि इसमें बैकट्रेस हैं जो मुझे प्रासंगिक जानकारी प्रदान करते हैं। इसके बिना, यदि मेरे कोड में एक से अधिक बार let ... = File::open() है, तो मैं पहले से ही यह नहीं पहचान सकता कि कौन सा विफल हुआ।

मैं आप लोगों के बारे में नहीं जानता, लेकिन जब मैं त्वरित "स्क्रिप्ट" लिखता हूं, तो मुझे बस unwrap() सब कुछ खत्म हो जाता है। यह 100 गुना बेहतर है, क्योंकि इसमें बैकट्रेस हैं जो मुझे प्रासंगिक जानकारी प्रदान करते हैं। इसके बिना, यदि मेरे कोड में एक से अधिक बार let ... = File::open() है, तो मैं पहले से ही यह नहीं पहचान सकता कि कौन सा विफल हुआ।

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

@ किक्सुनिल : वैकल्पिक रूप से, मैं एक अधिक विस्तृत त्रुटि प्रबंधन रणनीति और/या अधिक व्यापक लॉगिंग और/या डिबगिंग पसंद करूंगा।

मुझे लगता है कि "आरएफसी लागू करें" को चुना जा सकता है, है ना? कम से कम इसके अनुसार! :मुस्कुराओ:

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

use std::error::Error;

impl<E: fmt::Debug> Termination for Result<!, E> {
    default fn report(self) -> i32 {
        let Err(err) = self;
        eprintln!("Error: {:?}", err);
        ExitCode::FAILURE.report()
    }
}

impl<E: fmt::Debug + Error> Termination for Result<!, E> {
    fn report(self) -> i32 {
        let Err(err) = self;
        eprintln!("Error: {:?}", err);

        for cause in Error::chain(&err).skip(1) {
            eprintln!("Caused by: {:?}", cause);
        }
        ExitCode::FAILURE.report()
    }
}

https://github.com/rust-lang/rfcs/blob/f4b8b61a414298ba0f76d9b786d58ccdc34a44bb/text/1937-ques-in-main.md#L260 -L270

impl<T: Termination, E: Display> Termination for Result<T, E> {
    fn report(self) -> i32 {
        match self {
            Ok(val) => val.report(),
            Err(ref err) => {
                print_diagnostics_for_error(err);
                EXIT_FAILURE
            }
        }
    }
}

क्या कोई कारण है कि आरएफसी का यह हिस्सा लागू नहीं किया गया था?

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

इस सुविधा की स्थिति क्या है? क्या स्थिरीकरण का कोई प्रस्ताव है?

@ ग्रेजैक इस मुद्दे को बंद कर दिया जाना चाहिए, क्योंकि यह काफी समय पहले उतरा था।

सच है, और मैं थोड़ा भ्रमित हो गया, मैं Termination विशेषता में लिंक से यहां आया और मैं इसके बारे में पूछ रहा था, क्या termination_trait_lib के लिए कोई उचित समस्या है?

इस मुद्दे को बंद कर देना चाहिए

Termination के स्थिरीकरण को ट्रैक करने के लिए यह समस्या अभी भी खुली है।