उस RFC में 4 विशिष्ट विशेषताएं हैं और फिर भी हमारे पास अभी भी उन सभी के लिए केवल एक ट्रैकिंग समस्या है। क्या हम कृपया इस तरह की अलग-अलग विशेषताओं को एक साथ नहीं रख सकते हैं?

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

बक्से का नाम बदलने के लिए एक बाहरी तंत्र होना कुछ ऐसा है जो पहले से ही वांछित है और वर्षों से इसकी आवश्यकता है (https://github.com/rust-lang/cargo/issues/1311) और अकेले खड़े हो सकते थे, लेकिन इसके बजाय इसका उपयोग किया जा रहा है extern crate को मारने का समर्थन करने के लिए एक मोहरे से ज्यादा कुछ नहीं।

हमें अतीत में बारीकी से संबंधित सुविधाओं के लिए अलग RFC रखने में कोई समस्या नहीं हुई है ( repr(align(N)) और repr(packed(N)) लिए RFC का ध्यान आता है), फिर भी अब हम दावा कर रहे हैं कि foo/mod.rs बदलना foo.rs का extern:: और crate:: से इतना गहरा संबंध है कि उन्हें एक ही RFC में रहना होगा और एक ही ट्रैकिंग समस्या का उपयोग करना होगा?

बस यह सुनिश्चित करने के लिए कि यह बिंदु चारों ओर चिपक जाता है, क्योंकि यह वाक्यविन्यास अनसुलझे प्रश्न का अपेक्षाकृत सूक्ष्म पहलू है: crate का उपयोग दृश्यता संशोधक के साथ-साथ पथ उपसर्ग के रूप में crate ::absolute::path और के बीच एक पार्सिंग अस्पष्टता का परिचय देता है crate::relative::path । एक प्रासंगिक कीवर्ड का उपयोग करना समान अस्पष्टता का परिचय देता है, और कोई अन्य आरक्षित कीवर्ड नहीं हैं जो वास्तव में दृश्यता संशोधक के रूप में समझ में आते हैं।

इस प्रकार मैं crate दृश्यता संशोधक को छोड़कर मौजूदा pub(crate) साथ चिपके रहने के साथ (कम से कम) प्रयोग करना चाहता हूं।

मुझे foo.rs / foo/mod.rs बिंदु को एक अलग ट्रैकिंग समस्या में विभाजित करने में कोई आपत्ति नहीं होगी, क्योंकि यह वास्तव में पथ और दृश्यता संशोधक परिवर्तनों से स्वतंत्र प्रतीत होता है।

जहां तक ​​बाहरी क्रेट का नाम बदलने की बात है... इसके लिए पहले से ही एक अलग मुद्दा है? पथ परिवर्तन के लिए यह बहुत महत्वपूर्ण है इसलिए मुझे लगता है कि इसका भी हिस्सा होना ठीक है ।

दृश्यता संशोधक (पथ उपसर्ग नहीं) के रूप में crate की पसंद के संबंध में कुछ सप्ताह पहले बहुत सारी चर्चाओं के बावजूद, मुझे यह देखकर निराशा हुई कि हालांकि कीवर्ड की इस पसंद को 'अनसुलझे प्रश्न' के रूप में सूचीबद्ध किया गया था RFC, अब इसे स्पष्ट रूप से भुला दिया गया है। मैं स्वयं, और कई अन्य जिन्हें मैंने नोट किया है, इस विकल्प को भ्रमित करने वाला लगता है क्योंकि यह विशेषण/संशोधक नहीं है, और अस्पष्ट भी हो सकता है: क्या crate मतलब टोकरा के सार्वजनिक एपीआई का हिस्सा है? नहीं! इसका मतलब है local या internal या pub (लिश्ड) से टोकरा (इसलिए मैं बाद वाले कीवर्ड को पसंद करता हूं)। इसलिए मैं तत्काल बदलाव की मांग नहीं कर रहा हूं, लेकिन कम से कम इसे इस ट्रैकिंग मुद्दे में एक अनसुलझे प्रश्न के रूप में स्वीकार करता हूं, ताकि स्थिर होने पर इसे भुलाया न जाए।

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

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

@rpjohnst @ retep998 मैंने foo.rs + foo/ पर चर्चा करने के साथ-साथ इस RFC में कुछ सुधारों का प्रस्ताव करने के लिए एक नया RFC खोला

संपादित करें: मेरा सुझाव है कि हम दृश्यता संशोधक के रूप में crate पर चर्चा करने के लिए एक और RFC खोलें। व्यक्तिगत रूप से मैं इसके विपरीत देखना चाहता हूं: pub(extern) सभी बाहरी रूप से प्रकाशित प्रतीकों के लिए जोड़ा और आवश्यक है। यह अगले युग में नंगे pub को pub(crate) के बराबर बना देगा।

@rpjohnst

टोकरा :: पूर्ण :: पथ और टोकरा :: रिश्तेदार :: पथ के बीच एक पार्सिंग अस्पष्टता का परिचय देता है

वैसे भी crate ::relative::path अमान्य कोड नहीं है? क्या इसे पार्सिंग के दौरान खारिज नहीं किया जा सकता है?

@ est31 नहीं, इसके लिए पार्सिंग के दौरान नाम समाधान करने की आवश्यकता है जो निश्चित रूप से ऐसा कुछ नहीं है जिसे हम करना चाहते हैं। यह सी और सी ++ को पार्स करने के अधिक कष्टप्रद हिस्सों में से एक है, जिसमें समान अस्पष्टताएं a * b गुणन या घोषणा के रूप में होती हैं, और लगभग a b(c, d); एक चर घोषणा या एक फ़ंक्शन प्रोटोटाइप होने के नाते।

यदि हम कभी भी एक ही नाम के साथ निर्भरता और शीर्ष-स्तरीय मॉड्यूल की अनुमति देना शुरू करते हैं, यहां तक ​​कि पार्सिंग के साथ नाम समाधान को उलझाने से भी हमें कोई बचत नहीं होगी- crate :: some :: item एक crate -दृश्यमान item निर्भरता से some , या एक निजी item शीर्ष-स्तरीय मॉड्यूल some ।

इसे परिप्रेक्ष्य में रखने के लिए, हम मनमाने ढंग से अस्पष्टता को एक या दूसरे तरीके से हल कर सकते हैं और दूसरे मामले को लिखने के लिए कोष्ठक की आवश्यकता होती है (शायद crate -दृश्यता पूर्ण पथ मामला, जो दुर्लभ लगता है), लेकिन यह अभी भी एक है अगर हम pub(crate) चिपके रहते हैं, तो हमें इसकी आवश्यकता नहीं है, जो पहले से ही वाक्यात्मक अस्पष्टता को हल कर चुका है।

दृश्यता संशोधक के साथ-साथ पथ उपसर्ग के रूप में क्रेट का उपयोग crate ::absolute::path और crate::relative::path बीच एक पार्सिंग अस्पष्टता का परिचय देता है।

यह एक छोटा सा मुद्दा है, आईएमओ, यह देखते हुए कि टुपल स्ट्रक्चर फ़ील्ड और "इनलाइन" पूर्ण पथ दोनों दृश्यता दुर्लभ हैं।
पथों को हमेशा लालच से पार्स किया जाता है, इसलिए यह crate :: x :: y का अर्थ crate::x::y लिए समझ में आता है।
यदि विपरीत अर्थ की आवश्यकता हो तो pub(crate) ::x::y या crate (::x::y) का प्रयोग किया जा सकता है।

@rpjohnst @petrochenkov क्या आप कृपया एक कोड उदाहरण साझा कर सकते हैं जहां pub ::relative::path वैध कोड है? मुझे पूरी अस्पष्टता नहीं मिलती क्योंकि मुझे लगता है कि दो मामलों में से एक अमान्य है।

संपादित करें: एकमात्र स्थान जहां यह प्रासंगिक हो सकता है मैक्रोज़ के अंदर है जब आप दृश्यता क्वालीफायर + पथ के लिए मेल खाते हैं। लेकिन यह एक बहुत छोटा टूटना है इसलिए स्वीकार्य आईएमओ।

@ est31 ऐसा लगता है कि आपके पास गलत विचार है- यह सापेक्ष पथों के बारे में नहीं है, वे कभी भी कोई मुद्दा नहीं हैं। यह एएसटी के निर्माण के बारे में है इससे पहले कि आप जानते हैं कि कोई भी नाम क्या है। यहाँ एक पूर्ण नमूना है:

struct S(crate :: x :: y);

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

@rpjohnst मैं स्पष्ट करने के लिए धन्यवाद

@rpjohnst

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

    struct S(:: crate :: x :: y);

(मूल 'नेमस्पेस' को इंगित करने के लिए :: उपसर्ग पर ध्यान दें)

यह सबमॉड्यूल (जैसे ::std::x::y ) में अन्य रूट नेमस्पेस को संदर्भित करने की आवश्यकता के अनुरूप है।

मुझे लगता है कि बस crate -as-a-visibility को असंबद्ध करना कुछ आश्चर्यजनक होगा। लेकिन यह एक अच्छा विचार हो सकता है कि "कैनोनिकलाइज़" किया जाए जो थोड़ा सा काम करे और लागू करे कि crate:: हमेशा एक अग्रणी :: ( use s के बाहर) के साथ प्रयोग किया जाता है। जैसा कि आप इंगित करते हैं, यह ::std::x::y -समान पथों के साथ समरूपता को बढ़ाता है, और वास्तव में सापेक्ष पथों के लिए अन-प्रीफिक्स्ड फॉर्म छोड़ देता है ( self:: / super:: / something_in_scope:: )।

क्या हमें ऐसा करना चाहिए? crate::x::y को गैर- use रास्तों में अनुमति देना crate::x::y crate को जादुई बनाता है, जबकि ::crate::x::y को लागू करने से यह निर्भरता के समान स्तर तक

@rpjohnst

लागू करें कि crate:: हमेशा एक अग्रणी :: साथ प्रयोग किया जाता है (पाठ्यक्रम के उपयोग के बाहर)

यह उचित हो सकता है, कम से कम शुरुआत के लिए (कुछ भी बाद में इसे आराम करने से रोकता नहीं है)।

मैं use extern::bar::foo या use crate::bar::foo सिंटैक्स का प्रशंसक नहीं हूं। बहुत शोर-शराबा लगता है। मैं इसके लिए थोड़ी चीनी पसंद करूंगा। मैं इसके लिए extern bar::foo सुझाव देता हूं।

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

जैसे

1. हमारी परियोजना संरचना इस प्रकार है:

एसआरसी
|--lib.rs
|--foo.rs
|--फू
|----|--bar.rs

1. आप Cargo.toml में निर्भरता को कॉन्फ़िगर करते हैं, जैसे
   [dependencies] serde = "3.0.0"

2. हम mod bar को mod foo में जोड़ते हैं, और mod foo को lib.rs में जोड़ते हैं,

3. हम lib.rs में एक फ़ंक्शन finlib परिभाषित करते हैं, foo.rs में एक फ़ंक्शन finfoo परिभाषित करते हैं, bar.rs में एक फ़ंक्शन finbar परिभाषित करते हैं

बाहरी टोकरे के दायरे को टोकरा में शीर्ष स्तर के मॉड्यूल के रूप में बनाएं, फिर हम कहीं भी इस तरह कोड लिख सकते हैं।

पूर्ण/योग्य पथ के लिए

::serde::Deserialize
::serde::x::y
::finlib                            // not ::crate::finlib
::foo::finfoo                   // not ::crate::foo::finfoo
::foo::bar::finbar           // not ::crate::foo::bar::finbar

सापेक्ष पथ इस तरह लिखें

serde::Deserialize      // no need to write `use serde`
serde::x::y                   // no need to write `use serde`
finlib                          
foo::finfoo                  
bar::finbar       

हम सबसे पहले serdefinlibfoo को वर्तमान मॉड स्कोप में देखते हैं, यदि रूट नेमस्पेस तक, सपर मोड में लुकअप नहीं मिलता है। यदि नाम का विरोध है, तो हम इसके बजाय पूर्ण पथ लिखते हैं।

नाम देखने से बचने के लिए हम foo.rs में self::bar::finbar का भी उपयोग कर सकते हैं।

मैं इस पर चर्चा करने वाले पहले के धागे को नहीं ढूंढ पा रहा हूं, लेकिन संकलक उस तरह से काम करता था और इससे नाम समाधान के लिए बड़ी समस्याएं होती थीं। IIRC @pcwalton या @ arielb1 शायद अधिक जानते हैं।

इस अस्पष्टता का सबसे आसान समाधान क्रेट-स्थानीय दृश्यता संशोधक (यानी: pub(crate) प्रतिस्थापन) के लिए एक अलग कीवर्ड का उपयोग करना नहीं होगा। उदाहरण के लिए, local , जैसा कि पिछली RFC चर्चाओं में पहले भी कई बार सुझाया गया था। फिर struct S(local :: x :: y) struct S(crate :: x :: y) ।

यह सिर्फ <visibility> <absolute path> और <relative path starting with the new keyword> बीच एक और अस्पष्टता का परिचय देता है, क्योंकि नया कीवर्ड प्रासंगिक होना चाहिए।

@rpjohnst आह धिक्कार है .. लेकिन क्या यह एक समस्या नहीं है जिसे हल करने के लिए युगों को डिजाइन किया गया था? उदाहरण: वर्तमान युग में हम केवल pub(crate) , और फिर, अगले युग में, एक नया गैर-प्रासंगिक कीवर्ड पेश करते हैं जो अधिक 'एर्गोनोमिक' है।

@ नीयन 64 हाँ, लेकिन यह आरएफसी द्वारा दावा किया गया है कि इसे एक नए युग की आवश्यकता नहीं है। ऐसा लगता है कि यह दावा नहीं है।

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

एक बात जो मेरे साथ हुई है, क्षमा के साथ अगर इसे किसी एक चर्चा में पहले लाया गया है (मुझे याद नहीं है कि मैंने इसे पिछले जोड़े में देखा था):

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

एक संभावित समाधान self:: को mod:: पक्ष में समाप्त करना होगा। तब हमारे पास crate:: का अर्थ "निकटतम संलग्न टोकरा में" और mod:: का अर्थ "निकटतम संलग्न मॉड्यूल में" होगा, और यह स्पष्ट और सुसंगत होगा। हम संभावित रूप से उस मुद्दे को भी हल कर सकते हैं जहां fn दायरे में वस्तुओं को एक योग्य तरीके से संदर्भित करना संभव नहीं है, fn:: उपसर्ग को पेश करके, आश्चर्यजनक रूप से इसका अर्थ है "निकटतम संलग्न fn ". (मैंने इस बारे में नहीं सोचा है कि आगे जाने का कोई मतलब हो सकता है, और इसमें trait:: या impl:: जैसी चीज़ें भी हैं।)

@glaebhoerl यह एक दिलचस्प प्रस्ताव है। व्यक्तिगत रूप से, मुझे लगता है कि मैं पूर्ण पथ के लिए एक नया वाक्यविन्यास पेश करने और मौजूदा को बहिष्कृत करने के विचार के आसपास आया हूं। मुझे यकीन नहीं है कि यह वाक्यविन्यास कैसा दिखना चाहिए, लेकिन मैं नीचे एक संभावना का वर्णन करूंगा (जो मुझे पता है कि पहले फ़्लोट किया गया है)।

कल्पना कीजिए कि पथों के लिए हमारे पास निम्नलिखित व्याकरण था:

Path = AbsolutePath | RelativePath
AbsolutePath = 
    | `@` ID? 
    | `@` ID? `::` RelativePath
    | `self` :: RelativePath
    | `super` :: RelativePath
RelativePath = ID (`::` ID)*

इस व्याकरण के तहत, उदाहरण के लिए @crate से शुरुआत करके अन्य क्रेटों की चीजों का संदर्भ दिया जाएगा:

use <strong i="13">@std</strong>::collections::HashMap;

कोई स्थानीय टोकरा को केवल @ साथ संदर्भित करेगा, उदाहरण के लिए:

use @::something::in::my::crate;

(और use self::something बेहतर या बदतर के लिए आज की तरह ही रहता है।)

इसके बारे में कुछ अच्छा यह है कि पूर्ण पथ सापेक्ष पथ से पूरी तरह से अलग हैं, जिसका अर्थ है कि अब हमारे पास वांछनीय संपत्ति है कि कोई use से कोड में पथ को कॉपी-पेस्ट कर सकता है और यह काम करता है:

fn foo() {
    <strong i="24">@std</strong>::cmp::min(a, b) // OK
}

यह आज सच नहीं है, जो निश्चित रूप से समय-समय पर मुझे भ्रमित करता है।

हम crate आसपास पार्सिंग अस्पष्टता को भी खत्म करते हैं, ताकि आप pub Foo(crate @::MyType) या जो कुछ भी कर सकें और यह ठीक काम करता है।

(सामान्य तौर पर, सापेक्ष और निरपेक्ष पथ एक ही :: से शुरू होते हैं, कई बार दर्द का स्रोत रहा है, यह सच है।)

एक बात जो मुझे नहीं पता वह यह है कि @foo सबसे अच्छा है या नहीं। दूसरा विकल्प जो मुझे लगता है काम करता है और जिसके बारे में मैंने सोचा है वह है [] :

• [std]::collections और [crate]::collections // []::collections बहुत अजीब लगता है।

मुझे सच में नहीं लगता कि हमें सिर्फ रास्तों के लिए कोई नया सिगिल पेश करना चाहिए। :: को ::crate::foo में लागू करना @glaebhoerl की टिप्पणी को संबोधित करने और पार्सिंग अस्पष्टता को खत्म करने के लिए पर्याप्त है। यह crate:: लिए इच्छित मानसिक मॉडल को भी अधिक बारीकी से फिट करता है- यह वर्तमान क्रेट के नाम के लिए स्टैंड-इन है, self:: जैसे पथ उपसर्ग नहीं।

(सामान्य तौर पर, सापेक्ष और निरपेक्ष पथ एक ही :: से शुरू होते हैं, कई बार दर्द का स्रोत रहा है, यह सच है।)

मुझे यकीन नहीं है कि आपका इससे क्या मतलब है। मुझे नहीं लगता कि कोई भी सापेक्ष पथ :: , है ना?

@nikomatsakis @glaebhoerl इस बात से स्वतंत्र है कि मुझे आपके सुझाव पसंद हैं या नहीं (मैं वास्तव में दोनों के साथ रह सकता हूं), क्या हम कृपया RFC से चिपके रह सकते हैं? इस पर आगे और पीछे बहुत तरह से चर्चा की गई है और मुझे नहीं लगता कि बहस को फिर से खोलने से किसी को मदद मिलेगी। नवीनतम RFC के थ्रेड पर कुल 82 लोगों ने टिप्पणी की है (इससे पहले कुछ चर्चाएँ हुई थीं), कई लोग इसके बारे में बहुत दृढ़ता से महसूस कर रहे थे। मुझे लगता है कि इस बिंदु पर प्रस्ताव के आखिरी मिनट में बदलाव में उन्हें बदलाव की समीक्षा करने का मौका दिए बिना चुपके से उनके लिए अनुचित होगा।
विशेष रूप से मैं थोड़ा उलझन में हूं क्योंकि # 44721 में @nikomatsakis ने इस तर्क के साथ सुविधा के बारे में चर्चा

@ संकेतन और [] संकेतन दोनों प्रस्तावित किए गए हैं (मेरे साथ दोनों का समर्थक होने के नाते) लेकिन उन्होंने अंततः इसे नहीं बनाया, कम से कम यह मेरी धारणा है, उपयोगकर्ताओं से नकारात्मक प्रतिक्रियाओं के कारण .

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

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

एक अग्रणी @ एक अग्रणी :: तुलना में अंतर करना कैसे आसान है? :: पहले से ही Rust और C++ दोनों में एक स्थापित तंत्र है!

@rpjohnst - मैंने कहा कि आप जिस वाक्य में जवाब दे रहे हैं, @ नेत्रहीन अलग है। विस्तार करने के लिए: यह आप पर कूद पड़ता है। टोकन स्ट्रीम के आपके मानसिक मॉडल में अग्रणी बनाम आंतरिक स्थिति के भ्रमित होने का कोई खतरा नहीं है।

@ एक पूरी तरह से नया टोकन है जिसका कोई मतलब नहीं है, और यह पता लगाने के लिए "एक पल के विचार" से कहीं अधिक समय लगेगा। एक आंतरिक :: :: लिए अग्रणी :: एक सापेक्ष पथ हो सकता है।

@rpjohnst - :: अर्थ है (जो C++ या Rust के साथ अनुभव द्वारा प्रदान किया गया है) पर पर्याप्त प्रशिक्षण दिए जाने पर आपके कथन सही हैं। मैं सीखने की क्षमता और आंतरिक अंतर की बात कर रहा था। "एक ही प्रतीक एक अलग संदर्भ में उपयोग किया जाता है" कभी भी "एक अद्वितीय प्रतीक" के रूप में अलग-अलग नहीं होगा।

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

@Ichoran : मुझे लगता है कि जंग व्याकरण के लिए एक निश्चित शब्दार्थ ( @ ) के लिए नया टोकन जोड़ना हल्के में लिया जाने वाला कदम नहीं है, और मुझे थोड़ा संदेह है कि हम @nikomatsakis के साथ ऐसा करने के बहुत करीब हैं और दूसरों का प्रस्ताव। एक के लिए, क्योंकि हम बाद में भाषा के जीवन में किसी अन्य उद्देश्य के लिए इसका पुन: उपयोग नहीं कर सकते हैं (मुझे लगता है कि पथ कोड में इतने व्यापक हैं कि @ टोकन कई जगहों पर दिखाई दे सकते हैं)। मुझे यह भी आश्चर्य है कि रस्ट कोड की जटिलता की धारणा पर क्या प्रभाव पड़ता है। एक नौसिखिया के लिए उदाहरण के लिए सी ++ का उपयोग नहीं किया जाता है, मेरा मानना ​​​​है (लेकिन इस पर शोध नहीं है) जंग एक बहुत ही बारोक, डरावनी संकेतन वाली भाषा है। इस वर्ष के लिए रणनीतिक लक्ष्यों में से एक सीखने की क्षमता का अनुकूलन करना है और मुझे लगता है कि जंग की स्वीकार्यता है। तो शायद हमें @ कल्पना करते समय इस पर विचार करना होगा क्योंकि अंतर्ज्ञान यह कोड में खड़ा होगा (जो

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

@est31

इस बात से स्वतंत्र कि मुझे आपके सुझाव पसंद हैं या नहीं (मैं वास्तव में दोनों के साथ रह सकता हूं), क्या हम कृपया आरएफसी पर टिके रह सकते हैं?

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

मेरी भावना यह है कि इस समय सही काम करना है:

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

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

संपादित करें: साथ ही, मुझे पता है कि @ और [] पहले उठाए गए थे, हालांकि मुझे याद नहीं है कि वर्तमान के सापेक्ष होने के लिए @::foo नोटेशन का उल्लेख पहले किया गया था या नहीं टोकरा। तो मेरा मतलब विचार के लेखकत्व का दावा करने का नहीं है।

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

यह चर्चा सूत्र भी देखें:

https://internals.rust-lang.org/t/the-great-module-adventure-continues/6678

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

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

मैं किसी दिन इस उत्कृष्ट कार्य को स्थिर करने में सक्षम होना चाहता हूं =) और इसके लिए हमें किसी एक प्रकार को चुनने की आवश्यकता होगी ... इसलिए धागा।

व्यक्तिगत रूप से मैं @nikomatsakis द्वारा उल्लिखित @ सिंटैक्स का प्रशंसक हूं। यह संक्षिप्त है, और यथोचित आत्म-व्याख्यात्मक है। हमें यहां किसी प्रकार का नया सिंटैक्स पेश करना होगा, इसलिए आरक्षित नाम जैसे crate (यूघ) की तुलना में एक विशेष चार बेहतर है।

ऐसा लगता है कि हम अब दूसरे बाहरी पॉइंटर से निपटने की स्थिति में हैं, विशेष रूप से दिए गए https://github.com/rust-lang/cargo/issues/1311 को अब हल किया गया है (इसे पहले से ही बंद किया जाना चाहिए)। थोड़ी सी सलाह और @ बनाम crate सिंटैक्स पर निर्णय के साथ, मैं संभवतः इससे निपट सकता था। विचार?

दो लागू नहीं किए गए लिंट के लिए जोड़ा गया ट्रैकिंग समस्याएँ।

मेरे साथ ऐसा होता है कि हमारे पास एक छोटी संगतता समस्या है: अगर हमें extern crate निहित होना है, तो उस काम को करने में एक ब्रेकिंग बदलाव शामिल है - extern crate क्रेट को जोड़ने के लिए मजबूर करता है; यदि आप Cargo.toml में अतिरिक्त क्रेट निर्दिष्ट करते हैं, लेकिन lib.rs नहीं जो स्पष्ट रूप से एक साथ लिंक नहीं करते हैं (उदाहरण के लिए पैनिक = पैनिक = एबॉर्ट के साथ खोलना, या समान प्रतीक निर्यात करने वाले क्रेट) तो त्रुटियों का कारण बन सकता है। क्या हमने इसे एक गैर-समस्याग्रस्त टूटने के रूप में निर्धारित किया है?

मेरे साथ ऐसा होता है कि हमारे पास एक छोटी संगतता समस्या है: यदि हमें बाहरी टोकरा निहित होना है, तो उस काम को करने में एक ब्रेकिंग परिवर्तन शामिल है - बाहरी टोकरा बल टोकरे को जोड़ने के लिए; यदि आप Cargo.toml में अतिरिक्त क्रेट निर्दिष्ट करते हैं, लेकिन lib.rs नहीं जो स्पष्ट रूप से एक साथ लिंक नहीं करते हैं (उदाहरण के लिए पैनिक = पैनिक = एबॉर्ट के साथ खोलना, या समान प्रतीक निर्यात करने वाले क्रेट) तो त्रुटियों का कारण बन सकता है। क्या हमने इसे एक गैर-समस्याग्रस्त टूटने के रूप में निर्धारित किया है?

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

हाँ, हम स्पष्ट रूप से फ़ायरफ़ॉक्स में इस पैटर्न का उपयोग करते हैं - एक टॉपलेवल gkrust टोकरा है जिसमें केवल क्रेट के लिए बाहरी क्रेट स्टेटमेंट होते हैं जिन्हें लिंक करने की आवश्यकता होती है (ये रस्ट में लिखे गए बाहरी सी फ़ंक्शन को उजागर करते हैं जिन्हें फ़ायरफ़ॉक्स कॉल करता है)

आप इसे बाध्य करने के लिए lib.rs में लोगों को use cratename; आवश्यकता के साथ काम कर सकते हैं।

इस उद्देश्य के लिए #![link_crates(stylo,webrender)] विशेषता रखने के बारे में क्या? extern crate विपरीत, यह नाम के पेड़ में टोकरा नहीं जोड़ेगा। इसे एक नया नाम देने से पाठकों को स्पष्ट रूप से संकेत मिलेगा कि आप केवल लिंकेज के लिए क्रेट शामिल कर रहे हैं और यह कि कथन को हटाया नहीं जाना चाहिए, जबकि extern crate चाहिए।

हालांकि यह विपरीत समस्या हल करता है?

ओह, मैं देखता हूं, 2015 के युग के लोगों के लिए यह उन्हें युग बदलने के बिना अपने कोड को अपग्रेड करने देता है।

लेकिन इसका मतलब है कि _everyone_ को link_crates कुंजी का उपयोग करने की आवश्यकता होगी। यह आदर्श नहीं है।

इस उद्देश्य के लिए #![link_crates(stylo,webrender)] विशेषता होने के बारे में क्या? बाहरी टोकरे के विपरीत, यह टोकरा को नाम के पेड़ में नहीं जोड़ेगा।

उन क्रेटों के बारे में जो या तो केवल लिंक वाले टोकरे के रूप में, जंग के प्रतीकों वाले टोकरे के रूप में, या दोनों के रूप में उपयोग किए जा सकते हैं?

@whitequark यदि आप उन क्रेटों से प्रतीकों का उपयोग करते हैं, तो आपको मुफ्त में लिंकेज मिलेगा जैसा कि पहले से ही है। विशेषता उपयोग साइट पर होगी ताकि आप उपयोगकर्ता के रूप में क्रेट का उपयोग करने का निर्णय लें।

@Manishearth

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

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

मुझे नहीं लगता कि उस उद्देश्य के लिए आपके कोड में use cratename; होना अच्छा है क्योंकि यह लिंट और (सबसे महत्वपूर्ण) कोड पाठकों/लेखकों को भ्रमित करेगा, और इस प्रकार लगता है कि उस वैध के लिए एक समर्पित सुविधा होनी चाहिए (लेकिन शायद ही कभी) केस का उपयोग करें।

@ est31 link_crates के सिंटैक्स पर बाइकशेडिंग, इसे एक विशेषता के रूप में रखने के बजाय, हम extern crate foo; जैसा कुछ क्यों नहीं करते?

@रेटेप998
अच्छा विचार! :मुस्कुराओ:
https://github.com/rust-lang/rfcs/pull/2166 ने extern crate foo as _; भी पेश किया ताकि क्रेट के नाम को लिंकेज-ओनली क्रेट के लिए स्कोप/मॉड्यूल में लाने से बचा जा सके।

@ est31 लिंक_क्रेट्स के सिंटैक्स पर बाइकशेडिंग, इसे एक विशेषता के रूप में रखने के बजाय, हम बाहरी क्रेट फू जैसा कुछ क्यों नहीं करते ??

हालांकि, लंबे समय में extern crate सिंटैक्स से छुटकारा पाने के लिए संपूर्ण बिंदु है।

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

@SimonSapin लेकिन आगे बढ़ते हुए, अगर यह सिर्फ एक किनारे का मामला होने जा रहा है, तो शायद इसके लिए विशेष वाक्यविन्यास होने का कोई मतलब नहीं है, और एक विशेषता (जैसा कि ऊपर प्रस्तावित है) अधिक समझ में आएगा।

मुझे अभी भी लगता है कि use foo या use foo as _ यहां पर्याप्त होना चाहिए, वास्तव में

@Manishearth से सहमत हूं।

extern crate; पर मेरे विचार का सारांश:

लाभ:

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

नुकसान:

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

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

मैं नहीं देखता कि यह यहाँ चर्चा के लिए कैसे प्रासंगिक है; यह पहले से मर्ज किए गए RFC के विरुद्ध एक बिंदु है।

@Manishearth मैं और अधिक @ यहाँ lib.rs से बाहरी टोकरा हटा सकते हैं, लेकिन इसे एर्गोनॉमिक्स और सीखने की क्षमता के लाभों के लिए hello_world.rs लिए रख सकते हैं (लाइब्रेरी के उपयोगकर्ताओं के लिए, इसके लेखक नहीं)।

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

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

इसलिए, अगर मैं गलत नहीं हूं, तो यहां केवल शेष कार्यान्वयन बिंदु #48719 है। क्या कोई अब इससे निपट रहा है? यदि नहीं, तो मैं जा सकता हूँ, मुझे लगता है...

हां, हम #50260 . में सामान निकालने की कोशिश कर रहे हैं

शनिवार, अप्रैल 28, 2018, 9:15 पूर्वाह्न अलेक्जेंडर रेगुएरो नोटिफिकेशन @github.com . पर
लिखा था:

इसलिए, अगर मैं गलत नहीं हूं, तो यहां केवल शेष कार्यान्वयन बिंदु है

48719 https://github.com/rust-lang/rust/issues/48719 । कोई है

अब इससे निपटना? यदि नहीं, तो मैं जा सकता हूँ, मुझे लगता है...

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

48722 किया गया है। @ मनीषार्थ क्या आप ओपी को अपडेट कर सकते हैं, कृपया :)

@mark-im @Manishearth https://github.com/rust-lang/cargo/issues/1311 भी पूरा हो गया है, इसलिए हो सकता है कि उस बिंदु को चेकबॉक्स में बदलना और उस पर टिक करना उचित हो। हालांकि मैं उत्सुक हूं: जब कार्गो का उपयोग नहीं किया जाता है, तो आगे क्या होता है? (ऐसा नहीं है कि कोई समझदार कार्गो से बचता है...)

@alexreg एक टोकरा का नाम बदलने के लिए रस्टक को बताने के लिए कार्गो जिस तंत्र का उपयोग करता है वह कार्गो का उपयोग नहीं करने वाले लोगों के लिए समान रूप से सुलभ है: --extern name_rustc_sees=path_to_dep.rlib ।

ऐसा लगता है कि हम जल्द ही संपूर्ण कार्यान्वयन चरण समाप्त कर देंगे - जब https://github.com/rust-lang/rust/pull/47992 भूमि, वास्तव में। क्या मुझे कुछ याद आ रहा है? इसे आगे बढ़ाने में मदद करने में खुशी हो रही है अगर कोई बिट और बॉब करना बाकी है।

हाँ, यह रास्ते में है। मुझे इसे पूरा करने की ज़रूरत है जो मैं शायद जल्दी करूँगा
अगले सप्ताह।

गुरु, 3 मई, 2018 को शाम 7:51 बजे अलेक्ज़ेंडर रेगुएरो नोटिफिकेशन @github.com
लिखा था:

ऐसा लगता है कि हम जल्द ही कार्यान्वयन का पूरा चरण पूरा कर लेंगे - कब

47992 https://github.com/rust-lang/rust/pull/47992 भूमि, वास्तव में। पूर्वाह्न

मुझे कुछ याद आ रहा है? अगर कोई बिट है तो इसे आगे बढ़ाने में मदद करने में खुशी हो रही है
बॉब्स करना बाकी है।

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

@ मनीषार्थ अच्छी चीजें।

@aturon https://github.com/rust-lang/rust/pull/50260 के साथ उतरा, क्या सब कुछ लागू है?

किसी को उस योजना का लिंक मिला जो RFC के बाद प्रस्तावित की --extern क्रेट के आयात को प्रस्तावना में जोड़ा जाता है, और आदि)

इसे मिला: https://internals.rust-lang.org/t/the-great-module-adventure-continues/6678/205

चूंकि यह इतना महत्वपूर्ण परिवर्तन है, शायद RFC को अद्यतन किया जाना चाहिए?

RFC आमतौर पर अपडेट नहीं होते हैं; वे अंतिम युक्ति नहीं हैं। वे एक हैं
सर्वसम्मति निर्माण उपकरण।

सोम, जून 18, 2018 को रात 9:43 बजे, कौन? मैं?! सूचनाएं @

चूंकि यह इतना महत्वपूर्ण परिवर्तन है, शायद RFC को अद्यतन किया जाना चाहिए?

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

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

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

ध्यान दें कि एक प्रारंभिक 2018 संस्करण पूर्वावलोकन अब तैयार है, और इसमें मॉड्यूल सिस्टम परिवर्तन शामिल हैं। कृपया एक नज़र डालें और यहां प्रतिक्रिया दें!

@aturon अंतिम अद्यतन, और मॉड्यूल कार्य समूह की अंतिम बैठक, जिसके परिणामस्वरूप https://internals.rust-lang.org/t/the-great-module-adventure-continues/6678/205 हुआ , जिसमें विशेष रूप से कहा गया था " दो रूपों के साथ एक एकल मूल प्रस्ताव तक सीमित"। जहां तक ​​मेरी जानकारी है, यह अभी भी सच था। मुझे यह आभास हुआ कि दोनों के साथ प्रयोग का समर्थन करने के लिए, फीचर फ्लैग के माध्यम से रात में दोनों को लागू किया गया था।

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

कृपया एक नए प्रस्ताव के लिए https://internals.rust-lang.org/t/relative-paths-in-rust-2018/7883 देखें, 2018 पूर्वावलोकन से निर्माण। विशेष रूप से, यह प्रस्ताव रूट मॉड्यूल और सबमॉड्यूल के बीच अधिक स्थिरता और एकरूपता प्रदान करता है, और use कथनों और कोड में पथ के प्रत्यक्ष उपयोग दोनों में समान नाम रिज़ॉल्यूशन का उपयोग करता है।

नमस्ते, ::some::path बनाम crate::some::path पर बस मेरे 2 सेंट - मैं बाद वाले को पसंद करता हूं, मुख्य रूप से क्योंकि यह सादा अंग्रेजी के रूप में पढ़ना आसान है और पागल बाएं लटकते विराम चिह्न को नहीं छोड़ता है।

कृपया एक नज़र डालें और यहां प्रतिक्रिया दें!

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

crate enum Either<T, U> {
    A(T),
    B(U),
}

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

crate use crate::foo;

जैसा कि मैंने लिंट इश्यू में उल्लेख किया है कि pub(crate) को केवल crate बदलने से।

(नोट: मैं परिवर्तनों के किसी अन्य भाग के बारे में टिप्पणी नहीं कर रहा हूं, जो निरंतरता के लिए अच्छा लगता है, केवल pub(crate) से सादे crate में परिवर्तन।)

@seanmonstar अगले संस्करण पूर्वावलोकन में मॉड्यूल सिस्टम में प्रस्तावित अतिरिक्त परिवर्तनों के साथ, मैं उम्मीद कर रहा हूं कि crate::foo दुर्लभ हो जाएगा, और crate use crate:: एक विशेष रूप से दुर्लभ घटना की तरह लगता है।

प्रारंभिक 2018 पूर्वावलोकन में मॉड्यूल सिस्टम के साथ, आपको अपने क्रेट में गहरे संदर्भों के लिए भी crate:: लिखना होगा। प्रस्तावित मॉड्यूल प्रणाली के साथ, आप केवल आवश्यकता होगी crate:: आपके टोकरा में संदर्भ के लिए (उदाहरण के लिए, foo.rs से lib.rs के लिए, या foo से / bar.rs foo.rs करने के लिए), लेकिन आपके टोकरे में नीचे के संदर्भों के लिए नहीं (उदाहरण के लिए, lib.rs से foo.rs तक, या foo.rs से foo/bar.rs तक)। और आम तौर पर, मैं उच्च-स्तरीय मॉड्यूल में एक गहरे मॉड्यूल से कुछ फिर से निर्यात करने के लिए पुन: निर्यात (चाहे pub use या crate use ) की अपेक्षा करता हूं, न कि दूसरी तरफ।

तो सामान्य तौर पर मुझे crate use crate::foo; देखकर आश्चर्य होगा।

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

वर्तमान में:

// in filter/mod.rs
pub(crate) use ::generic::{Combine, Func};

// in filters/foo.rs
use ::filter::{Filter, Func};

लिंट चाहेगा कि मैं इसे इसमें बदल दूं:

// in filter/mod.rs
crate use crate::generic::{Combine, Func};

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

मैं @seanmonstar से पूरी तरह सहमत हूं। आइए इस कीवर्ड को तब तक ओवरलोड न करें जब तक कि हमें (जो हम नहीं करते)।

हाँ, आप सही कह रहे हैं कि _आमतौर पर बबल अप को पुनः निर्यात करता है, लेकिन शॉन की रूपरेखा के अनुसार _laterally_ पुनः निर्यात किया जाना भी एक चीज़ है। यह कुछ ऐसा है जिसे मैं सर्वो-मीडिया क्रेट के लिए भी करने पर विचार कर रहा हूं, क्योंकि फाइलें बहुत अच्छी तरह से विभाजित हैं, लेकिन इसका मतलब है कि हमारे सभी नोड कार्यान्वयन में बहुत सारे सामान्य आयात हैं।

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

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

यहां एक और उदाहरण है जिसमें मैंने अभी भाग लिया है जो crate कीवर्ड को एक दृश्यता संशोधक और पथ दोनों में जोड़ता है, जो crate use crate... उदाहरण से भी अधिक संभावना प्रतीत होता है।

वर्तमान:

pub(crate) struct Bar {
    pub(crate) foo: ::Foo,
}

pub(crate) struct Baz(pub(crate) ::Foo);

इस ट्रैकिंग समस्या के परिवर्तनों के साथ:

crate struct Bar {
    crate foo: crate::Foo,
}

crate struct Baz(crate crate::Foo);

मुझे व्यक्तिगत रूप से नया तरीका वर्तमान तरीके से अधिक भ्रमित करने वाला लगता है।

जब मैंने पहली बार pub(crate) को crate बदलने के लिए RFC को पढ़ा तो मुझे लगा कि यह बिना दिमाग के लग रहा है। इस क्षेत्र में बाकी संबंधित रस्ट सिंटैक्स की तुलना में pub(crate) बहुत अजीब लगता है।

लेकिन...

थोड़ा पिस्टन गेम को रस्ट 2018 में @seanmonstar के प्रति सहानुभूति crate छिड़का जाना संज्ञानात्मक रूप से परेशान करने

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

use crate::menu::{Sound, Volume};

crate mod color;

...

/// A type for storing text and an associated color it should
/// be drawn as.
crate struct ColoredText {
    crate color: types::Color,
    crate text: &'static str,
}

मैं स्पष्ट होना चाहता हूं कि मैं वास्तव में इस प्रस्ताव के बाकी हिस्सों (मॉड्यूल सिस्टम अपडेट) को पसंद करता हूं।

मुझे सहानुभूति है कि pub(crate) थोड़ा भारी और अजीब भी लगता है, लेकिन एक नंगे crate भी जगह से थोड़ा हटकर लगता है।

क्या हम crate का पुन: उपयोग करने के बजाय यहां एक अलग कीवर्ड पर विचार कर सकते हैं?

@ नीयन 64 सुझाया गया internal जो उचित लगता है, लेकिन अन्य भी हो सकते हैं। चूंकि हम रस्ट 2018 में कीवर्ड जोड़ सकते हैं, इसलिए हमारे पास इस पर विचार करने का अवसर है।

internal मुझे pub(crate) से भारी लगता है। यह कोई छोटा नहीं है और यह एक नया कीवर्ड है।

कैसे के बारे में int ? :पी

अंदर ( ins ), आंतरिक ( int ), संरक्षित ( pro ), स्थानीय ( loc ), गुप्त ( sec ), आंतरिक ( inn ) crate कीवर्ड के लिए बहुत सारे विकल्प हैं।

क्या int सी/सी++ डेवलपर्स के लिए भ्रमित करने वाला होगा? (पूर्णांक कीवर्ड)

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

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

व्यक्तिगत रूप से मुझे pub(crate) साथ समस्या दिखाई नहीं दे रही है। वाक्य रचना पहली नजर में स्पष्ट और स्पष्ट है और वास्तविक जंग के अनुरूप है। मुझे नहीं लगता कि आपको इसे इतनी बार टाइप करना होगा कि 5 अतिरिक्त कुंजी स्ट्रोक एक समस्या है।

@UtherII

कारण है कि हम के लिए एक संक्षिप्त नाम की जरूरत pub(crate) क्योंकि का एक बहुत (भी हो सकता है की सबसे अधिक) के वर्तमान का उपयोग करता है pub इसके साथ प्रतिस्थापित किया जाएगा।

जंग 2018 में, प्रभावी रूप से निजी वस्तुओं के लिए pub का उपयोग करना (क्योंकि वे निजी मॉड्यूल में दिखाई देते हैं) एक चेतावनी होगी। इसके बजाय ऐसी वस्तुओं के लिए pub(crate) उपयोग करना चाहिए। यह सम्मेलन कोड की पठनीयता में सुधार करेगा: एक आइटम अन्य क्रेटों के लिए दृश्यमान होता है यदि और केवल अगर इसे pub चिह्नित किया जाता है, जबकि वर्तमान में यह अन्य क्रेटों के लिए दृश्यमान है या नहीं, यह एक नज़र में स्पष्ट नहीं हो सकता है।

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

यह देखते हुए कि संस्करण मैनुअल ने सुझाव दिया है कि लोग यहां फीडबैक छोड़ दें, मैंने ऐसा करने का फैसला किया है।

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

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

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

#[path] को रस्ट 2018 में नेस्टेड मॉड्यूल के साथ कैसे काम करना चाहिए? (https://github.com/rust-lang/rust/issues/35016#issuecomment-409185342)

IIUC, अभी, दो फ़ाइलें src/lib.rs और src/bar.rs , कोई X है जिसे इसमें प्रतिस्थापित किया जा सकता है:

mod foo {
    #[path = "X/bar.rs"]
    mod bar;
}

ऐसा कि मॉड्यूल bar.rs जाएगा, क्योंकि bar.rs का पथ हमेशा src/foo/X/bar.rs जो अमान्य है क्योंकि निर्देशिका foo मौजूद नहीं है।

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

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

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

उस अर्थ में, मुझे कीवर्ड export (भले ही extern साथ भ्रमित करना संभव हो, लेकिन शायद यह विवादास्पद है क्योंकि extern crate मर चुका है?) export struct Foo; बहुत पठनीय दिखता है, और कुछ अन्य भाषाओं (ईश) के साथ संरेखित होता है। मुझे इस RFC या अन्य जगहों पर कीवर्ड के रूप में export का कोई उल्लेख नहीं मिला। तो वहाँ भी है कि इसके लिए जा रहा है।

पूर्णता के लिए, इसमें @seanmonstar , @johnthagen , et al द्वारा लाए गए उपयोग के मामले शामिल हैं।

export use crate::generic::{Combine, Func};

// Or even better using relative paths
export use ::generic::{Combine, Func};

export struct Bar {
    export foo: crate::Foo,
}

export struct Baz(export crate::Foo);

use crate::menu::{Sound, Volume};

export mod color;

// ...

/// A type for storing text and an associated color it should
/// be drawn as.
export struct ColoredText {
    export color: types::Color,
    export text: &'static str,
}

जो कुछ भी कहा गया है, मैं आग से pub(crate) को मारने के पक्ष में हूं। मैं crate , FWIW भी पसंद करता हूं।

@parasyte मैं export साथ जो समस्या देखता हूं वह यह है कि इसे "यह टोकरा निर्यात ____" के साथ भ्रमित किया जा सकता है (जो कि pub के लिए है), लेकिन मैं देखता हूं कि आप किस तरह से वकालत कर रहे हैं अलग परिप्रेक्ष्य।

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

मैंने कोई "आधिकारिक" प्रतिक्रिया नहीं सुनी है यदि यह अभी भी चर्चा के लिए खुला है?

@parasyte के सुझाव की तर्ज पर कुछ और शब्दों को पेश करने के हित में (मैं @johnthagen से सहमत export pub तुलना में pub(crate) ):

shared use ::generic::{Combine, Func};
shared struct ColoredText {
    export color: types::Color,
    export text: &'static str,
}

global use ::generic::{Combine, Func};
global struct ColoredText {
    export color: types::Color,
    export text: &'static str,
}

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

लोग pub(cr) या यहां तक ​​कि केवल cr बारे में कैसा महसूस करेंगे?

crate का उपयोग करना आगे बढ़ने के लिए बहुत अच्छा लगता है। यह पहले से ही एक कीवर्ड है, extern crate में इसका पिछला उपयोग समाप्त हो रहा है। इसका अन्य उपयोग पहले से ही दृश्यता pub(crate) ।

यदि आप विशेषण के रूप में टोकरा का उपयोग करके थोड़ा सा भेंगाते हैं तो यह विचलित करने वाला नहीं लगता। 'घर' जैसे शब्दों का प्रयोग विशेषण के रूप में ठीक ही किया जा सकता है। IANAअंग्रेज़ी प्रोफेसर.

मुझे लगता है कि एक टोकरा दृश्यमान वस्तु का पुन: निर्यात करना सुपर समस्याग्रस्त नहीं है। व्यक्तिगत तौर पर मैं ही कभी मॉड्यूल जो यह परिभाषित करता है, जो आप का मतलब है का एक सीधा माता पिता में एक आइटम reexported है (शायद) का उपयोग करना चाहते self के बजाय crate (seanmonstar के होते हुए भी कोड आयोजन के मामले ) उदा.

    mod detail {
        crate struct Foo;
    }

    crate use self::detail::Foo;

एक प्रकार के निरपेक्ष पथ के साथ संयुक्त दृश्यता के रूप में टोकरा का उपयोग करना (फिर से सीनमोनस्टार के उदाहरण का उपयोग करना) अधिक समस्याग्रस्त दिखता है: crate struct Foo(crate crate::Bar); के विपरीत pub(crate) struct Foo(pub(crate) ::Foo); । मेरी एकमात्र आशा यह है कि यह निर्माण लोकप्रिय नहीं है और इस प्रकार संक्रमण से यह टोकरा सूप नहीं बनेगा। उपयोगकर्ता स्पष्ट रूप से आयात करके इससे बच सकते हैं:

use crate::Bar;

crate struct Foo(crate Bar);

मुझे share या ऐसा कुछ का सुझाव पसंद है। give , provide , deliver , offer , serve , post , forward .. . यदि यह एक विशेषण होना चाहिए, तो इन सभी को प्रत्यय से बदला जा सकता है: shared , givable , providable , आदि।

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

यह क्रमशः pub और use से बहुत अलग नहीं है। और मुझे लगता है कि export कीवर्ड का उपयोग करने से कुछ भ्रम की स्थिति उत्पन्न होगी। pub(crate) वास्तव में एक तरह का आला है। यही कारण है कि मैंने अतीत में केवल pub का उपयोग करने का विकल्प चुना था। ;(

crate दृश्यता संशोधक का मुद्दा #53120 पर निकाला गया है। आगे की बहस और फैसले वहीं पर चलते रहने चाहिए।

mod.rs परिवर्तनों के मुद्दे को #53125 पर निकाल दिया गया है। आगे की बहस और फैसले वहीं पर चलते रहने चाहिए।

extern crate मूल्यह्रास के मुद्दे के साथ-साथ use crate_name::foo और crate_name::foo Just Work™ को https://github.com/rust-lang/rust/ पर निकाला गया है।

मॉड्यूल पथ प्रणाली चुनने का मुद्दा https://github.com/rust-lang/rust/issues/53130 पर निकाला गया है

इस मुद्दे से सभी बिट्स को अलग-अलग मुद्दों में निकालने के बाद; मैं इसके द्वारा इसे बंद कर रहा हूं।

@सेंट्रिल : https://doc.rust-lang.org/unstable-book/print.html#extern_prelude यहां लिंक्स। इस पर कहां चर्चा हो रही है? अगर यह जानकारी वास्तव में गुम है, तो क्या आप इसे ओपी में जोड़ सकते हैं?

@ सनमई-एनएल क्या आप मेरी याददाश्त को ताज़ा कर सकते हैं कि "बाहरी प्रस्तावना" क्या थी?

अगर यह सिर्फ use some_crate::foo::bar; करने की क्षमता है तो वह https://github.com/rust-lang/rust/issues/53128 होना चाहिए

इसमें से कुछ पर https://github.com/rust-lang/rust/issues/54230 में चर्चा की जा रही है

@ सनमाई-एनएल मेरा मानना ​​​​है कि समस्या मुख्य रूप से निदान के लिए है।

extern_prelude है crate_name::foo::bar के बाहर use (आयात) पथ।

@सेंट्रिल

क्या आप मेरी याददाश्त को ताज़ा कर सकते हैं कि "बाहरी प्रस्तावना" क्या थी?

सामान्य तौर पर, "प्रस्तावना" का उपयोग वर्तमान में उन सभी नामों के लिए किया जाता है जो पूरे टोकरे के दायरे में हैं और एक विशिष्ट मॉड्यूल से जुड़े नहीं हैं। (वास्तव में उनमें से बहुत सारे हैं।)

@petrochenkov तो उसके संबंध में "

@alexreg
--extern किए गए टोकरे पूरे टोकरे के दायरे में हैं, जबकि किसी विशिष्ट मॉड्यूल से जुड़े नहीं हैं।

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

@petrochenkov धन्यवाद, समझ में आता है।

इस मुद्दे से सभी बिट्स को अलग-अलग मुद्दों में निकालने के बाद; मैं इसके द्वारा इसे बंद कर रहा हूं।

@Centril वर्तमान बीटा संस्करण लिंक में ट्रैकिंग समस्याएँ यहाँ। क्या आप मूल टिप्पणी को नवीनतम जानकारी से अपडेट करेंगे ताकि लोगों को टिप्पणियों को लिखने की आवश्यकता न पड़े?