Rust: (मॉड्यूल) एक दृश्यता संशोधक के रूप में `क्रेट` के लिए ट्रैकिंग समस्या

दृश्यता संशोधक के रूप में crate के बारे में टिप्पणियाँ:

पार्सिंग अस्पष्टता

• https://github.com/rust-lang/rust/issues/44660#issuecomment -330105779
• https://github.com/rust-lang/rust/issues/44660#issuecomment -330265493
• https://github.com/rust-lang/rust/issues/44660#issuecomment -330268244
• https://github.com/rust-lang/rust/issues/44660#issuecomment -330271416
• https://github.com/rust-lang/rust/issues/44660#issuecomment -330274593
• https://github.com/rust-lang/rust/issues/44660#issuecomment -330283059
• https://github.com/rust-lang/rust/issues/44660#issuecomment -330537697
• https://github.com/rust-lang/rust/issues/44660#issuecomment -330598910
• https://github.com/rust-lang/rust/issues/44660#issuecomment -330699801
• https://github.com/rust-lang/rust/issues/44660#issuecomment -331609126
• https://github.com/rust-lang/rust/issues/44660#issuecomment -331612061
• https://github.com/rust-lang/rust/issues/44660#issuecomment -331680750
• https://github.com/rust-lang/rust/issues/44660#issuecomment -331683175
• https://github.com/rust-lang/rust/issues/44660#issuecomment -331687462

अप्राकृतिक / भ्रम / सुधार नहीं

• https://github.com/rust-lang/rust/issues/44660#issuecomment -330142301
• https://github.com/rust-lang/rust/issues/44660#issuecomment -406013863
  
  
  
  • https://github.com/rust-lang/rust/issues/44660#issuecomment -406026647
  
  
  • https://github.com/rust-lang/rust/issues/44660#issuecomment -406035818
  
  
  • https://github.com/rust-lang/rust/issues/44660#issuecomment -406069472
  
  
  • https://github.com/rust-lang/rust/issues/44660#issuecomment -406070896
  
  
  • https://github.com/rust-lang/rust/issues/44660#issuecomment -406271075
  
  
  • https://github.com/rust-lang/rust/issues/44660#issuecomment -406355868
  
  
  • https://github.com/rust-lang/rust/issues/44660#issuecomment -408676804 (+ भारी हाथ)
  
  
• https://github.com/rust-lang/rust/issues/44660#issuecomment -408690552
• https://github.com/rust-lang/rust/issues/44660#issuecomment -408696147
• https://github.com/rust-lang/rust/issues/44660#issuecomment -408707824
  
  
  
  • https://github.com/rust-lang/rust/issues/44660#issuecomment -408769188
  
  
• https://github.com/rust-lang/rust/issues/44660#issuecomment -409790996 (+ बाइकशेड)
• https://github.com/rust-lang/rust/issues/44660#issuecomment -409900466

एक अच्छा विचार

• https://github.com/rust-lang/rust/issues/44660#issuecomment -409959482

इसके बजाय pub(extern)

• https://github.com/rust-lang/rust/issues/44660#issuecomment -330262645

बाइक शेड

• https://github.com/rust-lang/rust/issues/44660#issuecomment -408679152
• https://github.com/rust-lang/rust/issues/44660#issuecomment -408681646
• https://github.com/rust-lang/rust/issues/44660#issuecomment -408682187
• https://github.com/rust-lang/rust/issues/44660#issuecomment -409910136
• https://github.com/rust-lang/rust/issues/44660#issuecomment -409942899
• https://github.com/rust-lang/rust/issues/44660#issuecomment -409972551

एक प्रारंभिक पूर्वावलोकन

• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/15?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/35?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/37?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/50?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/51?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/52?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/53?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/54?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/55?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/56?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/57?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/58?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/60?u=centril
• https://internals.rust-lang.org/t/rust-2018-an-early-preview/7776/62?u=centril

समर्पित धागा

• https://internals.rust-lang.org/t/visibility-modifiers-pub-super-vs-super/7838

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

मैं व्यक्तिगत रूप से pub(crate) लिखने के साथ ठीक हूं, इरादा बहुत स्पष्ट लगता है।
@johnthagen द्वारा दिया गया उदाहरण वास्तव में देखने में दर्दनाक है ( 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,
}

crate mod color; विशेष रूप से भ्रमित करने वाला लगता है, आपको निश्चित रूप से इस पर थोड़ा विचार करने की आवश्यकता है कि वहां क्या हो रहा है।

इनमें से कुछ उदाहरण बहुत सी- static -esque- सहज रूप से संबंधित हैं लेकिन वास्तव में आश्चर्यजनक रूप से अलग हैं।

@johnthagen के कारण उदाहरण मेरे लिए खराब नहीं है। वास्तव में, यह स्वाभाविक रूप से पढ़ता है और मुझे समरूपता पसंद है। यह एक तरह से खूबसूरत है।

यदि की पठनीयता:

crate struct ColoredText {
    crate color: types::Color,
    crate text: &'static str,
}

एक समस्या बन जाती है; फिर एक आईडीई/संपादक जो जंग के सिंटैक्स को समझता है, अलग-अलग रंगों के साथ अलग-अलग स्थितियों में crate टोकन को हाइलाइट कर सकता है। मुझे लगता है कि अंतर को अच्छी तरह से साफ़ करना चाहिए।

crate दृश्यता संशोधक के रूप में निश्चित रूप से अजीब है: यह एक ऐसी चीज़ के लिए बहुत जंग-विशिष्ट कीवर्ड का उपयोग करता है जो जंग के लिए विशिष्ट नहीं है। इसके लिए कोटलिन और सी# internal का उपयोग करते हैं।

मैं व्यक्तिगत रूप से pub को crate-visible के लिए पुन: उपयोग करना चाहता हूं, और दुनिया के दृश्यमान के लिए अधिक डरावना वाक्यविन्यास के लिए जाना चाहता हूं, जैसे pub* या pub! ।

इसे पहले भी लाया जा चुका है, लेकिन मुझे लगता है कि मुझे जो मूल मुद्दे दिखाई दे रहे हैं वे हैं:

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

// Here `crate` means the root of this crate.
use crate::menu::{Sound, Volume};

// Here, `crate` means: export crate::game::color
// The `crate` is referring to `color`, not the root.
crate mod color;

...

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

एक उदाहरण की तुलना में, कोटलिन/सी# से @matklad के internal का उपयोग करना।

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

internal mod color;

...

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

मैं यह नहीं कह रहा हूं कि internal सही कीवर्ड है (रस्ट पसंद करता है कि यह बहुत छोटा संक्षिप्ताक्षर है, और int दुर्भाग्य से C/C++/Java भ्रम से भरा है), लेकिन मैं व्यक्तिगत रूप से सोचता हूं कि दूसरा उदाहरण तुरंत अधिक पठनीय है।

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

pub(crate) का थोड़ा लंबा सिंटैक्स इतना बड़ा सौदा नहीं हो सकता है यदि pub आइटम जो क्रेट के बाहर पहुंच योग्य नहीं हैं, के लिए चेतावनी/त्रुटि नहीं बन रहे थे। मैं व्यक्तिगत रूप से चाहता हूं कि अगर मेरे पास pub(crate) struct Foo { ... } होता, तो संकलक यह महसूस कर सकता था कि $#$4 impl Foo #$ में सभी pub fn s स्पष्ट रूप से उपलब्ध नहीं हैं, और मुझे इसके बारे में परेशान नहीं करते हैं।

मुझे लगता है कि यह वर्तमान में रस्ट 2015 में सिर्फ व्यस्त काम है यदि मैं कभी भी pub struct Foo से pub(crate) struct Foo तक एक प्रकार को चिह्नित करता हूं, तो संकलक कैसे सभी जगहों पर चिल्लाता है कि कुछ अन्य pub fn s अचानक pub(crate) प्रकार का उपयोग कर मौजूद है, जब समस्या वास्तविक नहीं है, क्योंकि दूसरा प्रकार भी pub(crate) है।

मुझे pub को क्रेट-पब्लिक के रूप में फिर से उपयोग करने और export या विश्व-दृश्यमान निर्यात के लिए कुछ का उपयोग करने का @matklad का विचार भी मिलता है। लेकिन यह एक संस्करण के लिए बहुत बड़ा अंतर हो सकता है?

pub को क्रेट-पब्लिक के रूप में फिर से तैयार करना और विश्व-जनता के लिए एक नई दृश्यता जोड़ना वर्तमान संस्करण से पहले का प्रस्ताव था। मौजूदा शब्दार्थ में इस तरह के बदलाव को एक संस्करण के लिए भी बहुत कठोर माना जाता था, यही वजह है कि pub अब इसका वर्तमान अर्थ रख रहा है।

जो कम चर्चा और विचार किया गया था, मुझे लगता है, pub को पूरी तरह से एक लिंट के माध्यम से पुनर्व्यवस्थित कर रहा था। शायद हम लिंट को " pub पर चेतावनी दें जो टोकरे के बाहर पहुंच योग्य नहीं है" से " pub पर चेतावनी दें जो टोकरा के बाहर पहुंच योग्य है " पर स्विच कर सकते हैं और एक विशुद्ध रूप से वैकल्पिक pub(extern) जोड़ सकते हैं export कीवर्ड। यही है, किसी भी शब्दार्थ को न बदलें, बस एक लिंट-साइलेंसिंग सिंटैक्स जोड़ें।

मुझे संदेह है कि यह कम विघटनकारी होगा, इस धारणा के आधार पर कि टोकरा-सार्वजनिक वस्तुओं की तुलना में कम विश्व-सार्वजनिक वस्तुएं हैं। यह दृश्यता के वास्तविक व्यवहार के साथ सभी का सामना करने के बजाय pub के सहज (हालांकि सूक्ष्म रूप से गलत) अर्थ को "वर्तमान मॉड्यूल से निर्यात" के रूप में संरक्षित करेगा।

रस्ट पसंद करता है कि यह बहुत छोटा संक्षिप्ताक्षर है, और int दुर्भाग्य से C/C++/Java भ्रम से भरा है

एफडब्ल्यूआईडब्ल्यू, हालांकि यह केवल दो वर्णों को बचाता है, अगर हम internal को संक्षिप्त करना चाहते हैं, तो "सही" संक्षिप्त नाम संभवतः, extern अल के अनुरूप होगा, intern होगा। दुर्भाग्यपूर्ण है कि वह भी एक सामान्य रूप से समझी जाने वाली, भिन्न अर्थ वाली संज्ञा है। ओह अच्छा।

@glaebhoerl intern विचार करने के लिए एक अच्छा विकल्प है! ❤️

extern के साथ समरूपता वास्तव में अच्छी है, और आईएमओ intern के संज्ञा रूप के साथ संभावित भ्रम को बहुत कम कर देगा।

यह छोटा है, ( crate से केवल 1 अधिक वर्ण) और use crate:: से टकराता नहीं है।

अद्यतन उदाहरण इस तरह दिखेगा:

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

intern mod color;

...

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

मैंने पहले इसका उल्लेख किया है, लेकिन मुझे यकीन नहीं है कि विशेषण के रूप में उपयोग की जाने वाली संज्ञाओं के साथ समस्या क्या है?

संक्षेप में: ऐसे बहुत से संज्ञाएं हैं जिनका उपयोग विशेषण के रूप में किया जा सकता है, उदाहरण के लिए। एक घरेलू बिल्ली, एक कंप्यूटर माउस, एक कंप्यूटर डेस्क, आदि... विशेषण के रूप में उपयोग की जाने वाली _अंग्रेजी संज्ञाओं के लिए एक Google खोज यह इंगित करती है कि स्वाभाविक रूप से कुछ भी गलत नहीं है, हालांकि सभी संज्ञाएं विशेषण के रूप में काम नहीं करती हैं।

चलो यह कोशिश करते हैं:

_क्रेट मॉड हैलो;_ हैलो नाम का एक क्रेट मॉड्यूल, ठीक लगता है।
_क्रेट fn वर्ल्ड() {}_ वर्ल्ड नाम का एक क्रेट फंक्शन, अच्छा लगता है।
_क्रेट स्ट्रक्चर फू;_ फू नाम का एक क्रेट स्ट्रक्चर, ठीक लगता है।
_क्रेट एनम बार {}_ बार नाम का एक क्रेट एनम, अच्छा लगता है।
_क्रेट ट्रेट बाज़ {}_ बाज़ नाम की क्रेट विशेषता, अच्छा लगता है।

_क्रेट यूज़ सेल्फ::लोकल::फू;_ एके, यह काम नहीं करता, एक टोकरा उपयोग? आप इसे फू नामक टोकरा प्रयोग करने योग्य वस्तु के रूप में पढ़ सकते हैं। यह पैटर्न को तोड़ता है।

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

जबकि टोकरा सही नहीं है, मुझे विश्वास नहीं है कि 'संज्ञा होना' एक निर्णायक कारक है।

समस्या यह है कि यह बहुत ही असामान्य है। कोई प्रोग्रामिंग भाषा नहीं है जो मुझे पता है कि संज्ञाओं को टाइप संशोधक के रूप में उपयोग करें।

@सेंट्रिल

एक समस्या बन जाती है; फिर एक आईडीई/संपादक जो रस्ट के सिंटैक्स को समझता है, अलग-अलग रंगों के साथ अलग-अलग स्थितियों में टोकरा टोकन को हाइलाइट कर सकता है। मुझे लगता है कि अंतर को अच्छी तरह से साफ़ करना चाहिए।

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

@epage मुझे लगता है कि crate एक दृश्यता संशोधक के रूप में हाइलाइटिंग के बावजूद एक अच्छा विचार है; मैं केवल यह सुझाव दे रहा हूं कि हाइलाइट करना अतिरिक्त शमन है। विशेष रूप से, किसी भी संपादक के लिए crate:: को crate field से अलग हाइलाइट करना काफी मामूली होना चाहिए क्योंकि पूर्व हमेशा crate + :: होता है जिसे जांचना आसान होता है for crate ::foo::bar को छोड़कर सभी मामलों में (लेकिन यह काफी दुर्लभ होगा ..)।

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

मुझे ऐसा लगता है कि dom (यानी: घरेलू) एक संभावित उम्मीदवार है।

इसमें तीन अक्षर हैं (संरेखण के लिए अच्छा, याद रखने में आसान), यह एक संज्ञा नहीं है, और - 'डॉक्यूमेंट ऑब्जेक्ट मॉडल' के अलावा - मुझे नहीं लगता कि इसमें कोई विशेष अस्पष्टता जुड़ी हुई है।

pub struct MyStruct {
    dom num: i32,
    pub msg: String,
}

क्या किसी के पास इस पर विचार है?

इस पर एक कोण जिसका मैंने उल्लेख किया है लेकिन सारांश में नहीं मिला (उस बीटीडब्ल्यू करने के लिए धन्यवाद!) यह है कि शॉर्टकट मौजूदा pub() सिंटैक्स के साथ कैसे फिट बैठता है।

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

उदाहरण के लिए, यदि हम crate या प्रतिस्थापन का उपयोग करते हैं:

• क्या crate को स्कोपिंग प्रतिबंधों (जैसे crate(<something>) ) को लेने के लिए बढ़ाया जाना चाहिए?
• क्या हमें pub() पदावनत करना चाहिए, इसलिए pub केवल एक ही अर्थ है?

इसे और लक्ष्य की मेरी समझ (आंतरिक एपीआई से सार्वजनिक एपीआई को स्पष्ट करें) को ध्यान में रखते हुए, मुझे @vitral के pub(extern) के विचार को फिर से बनाने के लिए प्रेरित किया।

• मौजूदा मशीनरी के भीतर फिट बैठता है
• imo एक विशेष मामला होने के बजाय pub को pub(<something>) का शॉर्टकट बनाकर मौजूदा मशीनरी में सुधार करता है
• यदि सार्वजनिक एपीआई निजी एपीआई से काफी छोटा है, तो हमने सिंटैक्स को सही तरीके से भारित किया है।
• लेकिन अन्य भाषाओं से आने वाले लोगों को भ्रमित कर सकता है जहां public का अर्थ है कि यह आपके सार्वजनिक एपीआई में हो सकता है।

एनकैप्सुलेशन पर आरई प्रभाव

मौजूदा pub प्रणाली का एक लाभ एनकैप्सुलेशन है। आसान रास्ता एपीआई को केवल एक-स्तर ऊपर उजागर करना है। इससे टोकरे के कुछ हिस्सों के लिए चीजों को सार्वजनिक करना आसान हो जाता है लेकिन पूरी रचना के लिए निजी।

जबकि अभी भी pub(super) होगा, pub(crate) के लिए शॉर्टकट होने से लोगों को इसे और अधिक उपयोग करने की दिशा में आगे बढ़ाया जाएगा, लोगों को अपने एपीआई को एनकैप्सुलेट नहीं करने के लिए प्रोत्साहित किया जाएगा।

मुझे संदेह है कि छोटे बक्से की संस्कृति के कारण यह कोई मुद्दा नहीं है।

लेकिन इस पर विचार करते हुए, यह मुझे pub(extern) . पर मेरी उपरोक्त टिप्पणी पर एक और पुनरावृत्ति देता है

• pub pub(super) . के लिए एक शॉर्टकट होना चाहिए
• आपके सार्वजनिक API के लिए pub(extern) आवश्यक है।

मैंने पहले अन्य भाषाओं से संक्रमण करने वाले लोगों की चिंता को सामने लाया था। यह उनके साथ बेहतर संरेखित करता है।

• विभिन्न भाषाओं में public के काम करने के तरीके से अधिक निकटता से मेल खाता है
• कुछ भाषाओं में सार्वजनिक एपीआई के लिए एक अलग तंत्र होता है, इसलिए यह उनके लिए समझा जा सकता है।

इमो यह सभी दुनिया में सबसे अच्छा है। तो इसे अलग करें और मुझे यह समझने में मदद करें कि क्यों नहीं :)

मुझे अभी भी pub(foo) सिंटैक्स से नफरत है। अतिशयोक्तिपूर्ण रूप से, ऐसा लगता है कि यह तय नहीं कर सकता कि यह एक फ़ंक्शन कॉल है या एकाधिक कीवर्ड का मैशअप है। हम let(mut) या for(in) का उपयोग नहीं करते हैं तो इस के साथ क्या सौदा है?

@parasyte pub<foo> जीत के लिए! आखिरकार, क्या यह _प्रकार की दृश्यता_ नहीं है?

pub<crate> या pub(crate) वास्तव में बेहतर महसूस करते हैं।

शिविर बदलने वाले किसी व्यक्ति के कुछ विचार:

पहले तो मैं crate का बहुत विरोध करता था और सोचता था कि "यह अच्छे pub को बर्बाद कर रहा है"।

फिर मैंने इसे अपनी कुछ परियोजनाओं में साथ-साथ करने की कोशिश की और इसे डूबने दिया।

सच कहूँ तो, कुछ दिनों के बाद मैं pub(X) को और नहीं देख सकता था, यह तुलना में भद्दा लगता है, और पढ़ने में कठिन होता है।

शुरू में मुझे डर था कि (दृश्य) अस्पष्टता हो सकती है; लेकिन मेरे साथ विपरीत हुआ: अगर मुझे अब crate दिखाई देता है तो मुझे पता है कि यह "टोकरा सामान" है। चाहे वह मॉड्यूल आयात कर रहा हो या दृश्यता घोषित कर रहा हो। संदर्भ से बहुत स्पष्ट अधिकांश मामलों में वास्तव में क्या है (अंग्रेजी में अस्पष्टता की तरह)।

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

उस कोण से crate - intern (या कोई अन्य विषमता) भी एक कदम पीछे की तरह महसूस होगा।

यह कहने के बाद, मैं अस्पष्टता को पार्स करने के बारे में नहीं जानता। अगर मुझे किसी एक को चुनना होता, तो " crate ::foo::bar जस्ट वर्क्स" के इर्द-गिर्द एक अच्छी कहानी के बजाय " crate का अर्थ क्रेट स्टफ" के आसपास एक अच्छी कहानी होती।

मेरे दो सेंट हैं:

• मैं crate mod , crate struct , crate fn , ... का व्यापक रूप से उपयोग कर रहा हूं और मुझे यह बेहद उपयोगी लगता है।
• मुझे वास्तव में परवाह नहीं है कि इसका नाम कैसे रखा गया है ( crate , pub(crate) , ...) जब तक कि यह अधिक लंबा न हो क्योंकि मैं इसे अक्सर उपयोग करता हूं।

यदि यह मेरे ऊपर होता, तो मैं कीवर्ड के रूप में vis और संशोधक के रूप में दृश्यता के प्रकार का उपयोग करता, उदाहरण के लिए vis(pub) , vis(crate) , आदि क्योंकि यह अधिक बनाता है मेरे लिए भावना।

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

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

उन लोगों के लिए जो पहले से उपयोग किए गए कीवर्ड का सुझाव देते हैं (यानी: crate ) अर्थों को भ्रमित करते हैं, मैं तर्क दूंगा कि संदर्भ शब्द से अधिक महत्वपूर्ण है। मस्तिष्क संदर्भ के साथ सब कुछ पार्स करता है (संकलक इसे कैसे पार्स करता है यह एक अलग मामला है): यह बताता है कि हम for for x in y और impl X for Y में क्यों नहीं जोड़ते हैं .

समान रूप से, crate को एक दृश्यता क्वालीफायर के रूप में पेश करने से संभवतः भ्रम पैदा नहीं होगा क्योंकि इसका अर्थ, किसी सदस्य या फ़ंक्शन क्वालीफायर के संदर्भ में, उस अतिरिक्त संदर्भ के साथ प्रदान किए जाने पर स्पष्ट है। उदाहरण के लिए, crate fn my_func(); "यह एक टोकरा है" के रूप में नहीं पढ़ता है, यह "यह एक टोकरा-दृश्यमान कार्य है" के रूप में पढ़ता है।

उस ने कहा, तथ्य यह है कि यह एक संज्ञा है असंगत है। मैं इस मुद्दे को हल करने के लिए एक नया दृश्यता क्वालीफायर कीवर्ड बनाना चाहता हूं।

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

किसी ऐसे व्यक्ति के रूप में जिसने crate को pub(crate) के प्रतिस्थापन के रूप में और @aturon की नवीनतम पोस्ट को पढ़ने के बाद उपयोग करने के बारे में चिंता व्यक्त की है:

एक दृश्यता संशोधक के रूप में सहायक टोकरा (यहां ट्रैक किया गया 138। अब तक प्रतिक्रिया को देखते हुए, यह सुविधा जंग 2018 के लिए स्थिर होने की संभावना नहीं है ।

मैं केवल यह सुनिश्चित करना चाहता हूं कि मैं स्पष्ट हूं कि मैं व्यक्तिगत रूप से pub(crate) को किसी चीज़ से बदलने के पक्ष में हूं (जैसा कि मुझे लगता है कि बहुमत है)।

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

1. intern (या कुछ अन्य समान नए कीवर्ड)
2. crate
3. pub(crate)

अगर कोर टीम को ऐसा लगता है कि intern या ऐसा ही कुछ अंततः कभी स्वीकार नहीं किया जाएगा, तो मैं crate से पीछे हो जाऊंगा क्योंकि मुझे अभी भी लगता है कि यह pub(crate) पर एक बड़ा सुधार है, क्योंकि @Centril और अन्य ने इसके कारणों को स्पष्ट किया है।

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

@राल्फबीडर्ट

शुरू में मुझे डर था कि (दृश्य) अस्पष्टता हो सकती है; लेकिन मेरे साथ इसके विपरीत हुआ: अगर मैं अब टोकरा देखता हूं तो मुझे पता है कि यह "टोकरा सामान" है। चाहे वह मॉड्यूल आयात कर रहा हो या दृश्यता घोषित कर रहा हो। संदर्भ से बहुत स्पष्ट अधिकांश मामलों में वास्तव में क्या है (अंग्रेजी में अस्पष्टता की तरह)।

@zesterer

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

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

जबकि मुझे यह अजीब लग रहा है, मेरी सबसे बड़ी चिंता गैर-जंगली लोगों के साथ है।

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

मुझे यह अच्छा लगेगा अगर हम इस पर उपयोगिता अध्ययन कर सकें ताकि यह पता चल सके कि इन चिंताओं का कितना प्रभाव पड़ता है।

@epage , बहुत सहमत हैं, जंग के उपयोगकर्ता-सामना करने वाले हिस्सों को यूएक्स परीक्षण किया जाना चाहिए। हालाँकि, मुझे लगता है कि अभी यही हो रहा है, और हम परिणामों पर चर्चा करने के बीच में हैं।

उसमें जोड़ने के लिए, हमारी कंपनी से कुछ महत्वपूर्ण टिप्पणियां:

मैं अपने विभाग में "रस्ट एडवोकेट" हूं, 3 अन्य लोगों के साथ काम कर रहा हूं। सभी की सी # में एक ठोस पृष्ठभूमि है, लेकिन जंग के लिए अपेक्षाकृत नए हैं। दूसरे दिन मैंने " crate -stuff" के साथ अपनी शोध परियोजना को Rust 2018 में स्थानांतरित कर दिया।

जब हमने कोड का अध्ययन किया, तो बातचीत लगभग इस प्रकार हुई:

"तो यहाँ कुछ अन्य परिवर्तन हैं जो मैंने किए; नई आयात प्रणाली; संशोधक।"

"यह क्या करता है?" ( use crate::object और crate x: object की ओर इशारा करते हुए)

"इस टोकरे से आयात करें।" और "दृश्यता संशोधक।"

"आह, ठीक है। कुछ और जो बदल गया?"

चर्चा का अंत।

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

अगली बार जब हम बात करेंगे तो अगर मैं कुछ और सुनूंगा तो मैं इस टिप्पणी को अपडेट कर दूंगा।

@ralfbiedert इसे साझा करने के लिए धन्यवाद!

@epage , बहुत सहमत हैं, जंग के उपयोगकर्ता-सामना करने वाले हिस्सों को यूएक्स परीक्षण किया जाना चाहिए। हालाँकि, मुझे लगता है कि अभी यही हो रहा है, और हम परिणामों पर चर्चा करने के बीच में हैं।

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

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

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

तो, मेरे लिए, $#$2$# pub के बजाय crate या उस प्रकृति के किसी अन्य कीवर्ड का उपयोग करना बस खुजली महसूस करता है: यदि सार्वजनिक होना गैर-डिफ़ॉल्ट है, तो टोकरा से निर्यात किया जाना और भी विशेष होना चाहिए . यानी क्रेट के एपीआई को खास तरीके से निरूपित किया जाना चाहिए।

इसलिए, मैं @epage से तहे दिल से सहमत हूं, pub को वही रहना चाहिए और किसी प्रकार का pub(extern) पेश किया जाना चाहिए। हालांकि, कोष्ठक में दिए गए कीवर्ड वास्तव में बालों वाले लगते हैं, इसलिए हो सकता है कि यह एक समर्पित कीवर्ड के लायक हो। crate कीवर्ड उस अर्थ में काम करेगा, मैं इसका अर्थ देख सकता हूं "यह एक निर्यातित क्रेट सदस्य" है। या export वास्तव में, मुझे नहीं पता। हो सकता है कि मेरी सारी बात बिक गई हो, और यह सब "कीवर्ड सही नहीं हैं" के बराबर है। लेकिन pub इतना सामान्य है कि यह विशेष महसूस नहीं करता है, इसलिए इसे वास्तव में कुछ विशेष (टोकरा-निर्यात एपीआई) का प्रतिनिधित्व नहीं करना चाहिए।

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

@steveklabnik

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

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

देखो

• मेरी चिंता
• एक और चिंता और एक प्रस्तावित समाधान

@ सुपरसीड

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

आरई "कोष्ठक आकार वाले कीवर्ड वास्तव में बालों वाले लगते हैं"

जबकि व्यक्तिगत रूप से मैंने सोचा था कि जब मुझे उनके बारे में पता चला तो वे साफ-सुथरे थे (सभी-या-कुछ भी friend से बहुत बेहतर), मेरी बड़ी चिंता यह है कि हम एक समानांतर वाक्यविन्यास नहीं बनाते हैं, लेकिन या तो हमारे पास जो कुछ भी है उसे गले लगाते हैं या पाते हैं एक वैकल्पिक समाधान।

दूसरी ओर...

आरई या export वास्तव में,

मुझे नहीं लगता कि export जोड़ने से मेरी पिछली टिप्पणी crate के विपरीत है। इस संदर्भ में, export को दृश्यता से भिन्न माना जा सकता है। export का अर्थ होगा pub(crate) । मुझे संदेह है कि इससे शिक्षण में ज्यादा समस्या नहीं होगी।

मैं अपने मूल विचार के इस विस्तार पर किसी भी तरह से जा सकता हूं।

@ सुपरसीड

pub [...] दृश्यता "एक स्तर से ऊपर"।
crate कीवर्ड उस अर्थ में काम करेगा, मैं इसका अर्थ देख सकता हूं "यह एक निर्यातित क्रेट सदस्य" है।

मुझे लगता है कि इन दो खोजशब्दों के अर्थ के बारे में आपकी समझ यहाँ प्रस्तावित के ठीक विपरीत हो सकती है, जो यह है कि pub का अर्थ सभी के लिए सार्वजनिक है जबकि crate का अर्थ एक ही टोकरे से पहुँचा जा सकता है।

@epage

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

@SimonSapin

वास्तव में, और मुझे एहसास है कि जिस तरह से इसे समझा जाना चाहिए, लेकिन crate - एक संज्ञा होने के नाते - ऐसा लगता है कि यह या तो एक टोकरा (?) या टोकरा की संपत्ति घोषित कर रहा है। घोषित करने और योग्य नहीं होने पर जोर।

और public / pub एक ऐसा सर्वव्यापी क्वालीफायर है, ऐसा नहीं लगता (मेरे लिए!) जैसे इसका मतलब होना चाहिए "यह टोकरा से निर्यात किया जाता है"। इसका अर्थ यह है कि "यह मेरे संदर्भ के ठीक बाहर से दिखाई दे रहा है", जैसा कि struct सदस्य दृश्यता को अर्हता प्राप्त करने में इसके उपयोग के मामले में है (और अगर मैं गलत हूं तो मुझे सही करें लेकिन मैं नहीं करता ' मुझे नहीं लगता कि उस मामले में शब्दार्थ बदल रहे हैं)।

और सार्वजनिक/पब एक ऐसा सर्वव्यापी क्वालीफायर है, ऐसा नहीं लगता (मेरे लिए!) जैसे इसका मतलब होना चाहिए "यह टोकरा से निर्यात किया जाता है"। इसका अर्थ यह है कि "यह सिर्फ उस संदर्भ के बाहर से दिखाई देता है जिसमें मैं हूं", जैसा कि क्वालीफाइंग स्ट्रक्चर सदस्य दृश्यता में इसके उपयोग के मामले में है (और अगर मैं गलत हूं तो मुझे सही करें लेकिन मुझे नहीं लगता कि अर्थशास्त्र हैं हैं उस मामले में बदल रहा है)।

pub का अर्थ हमेशा "यह टोकरा से निर्यात किया जाता है" - यह कोई बदलाव नहीं है, यह पहले से ही ऐसा है। तथ्य यह है कि इतने सारे लोग अन्यथा मानते हैं कि क्यों pub(crate) दृश्यता स्तर को बिल्कुल धक्का दिया जा रहा है।

पब का हमेशा मतलब होता है "इसे टोकरा से निर्यात किया जाता है"

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

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

@rpjohnst क्या वास्तव में इसका हमेशा मतलब होता है? क्या यह टोकरे के ऊपर से " super से दृश्यमान" की श्रृंखला नहीं थी, जिसने एक तत्व को निर्यात किया, और पत्ती तत्व को स्वयं के रूप में योग्य नहीं बनाया pub ?

नहीं, यह पूरी कहानी नहीं है, और @seanmonstar का स्पष्टीकरण बाकी की ओर इशारा करता है। सबसे बड़ा अपवाद reexports है- आप pub use कुछ ऐसा कर सकते हैं जिसके मूल मॉड्यूल निजी हैं। एक अजीब उदाहरण कुछ इस तरह है , जहां आपको सार्वजनिक इंटरफ़ेस में pub आइटम का उपयोग करने की अनुमति है, भले ही उसके मूल मॉड्यूल निजी हों।

और दूसरी दिशा में जा रहे हैं, pub(crate) और कम दृश्यता को उसी तरह से बायपास नहीं किया जा सकता है- आप pub use कुछ ऐसा नहीं कर सकते जो पहले से pub नहीं है, भले ही pub use खुद टोकरे के बाहर से दिखाई नहीं दे रहा है।

तो किसी वस्तु की अपनी दृश्यता सीधे उसकी super की दृश्यता के बारे में नहीं है, बल्कि इसकी "ऊपरी सीमा" कहीं भी दृश्यता है।

ओह ठीक है, स्पष्टीकरण के लिए धन्यवाद! मेरे मन में बहुत अधिक भोली मॉडल थी। यह "पब के वर्तमान अर्थ" के बारे में पिछली टिप्पणियों के बारे में अधिक समझ में आता है।

हमने आज @rust-lang/lang बैठक में संक्षेप में चर्चा की:

• हम में से बहुत से लोग इसके बारे में सकारात्मक महसूस करते हैं लेकिन कीवर्ड की पसंद के बारे में संदेह है, और क्या यह crate::foo::bar पथों के साथ संयुक्त होने पर भ्रम पैदा कर सकता है।
• हालांकि, यह इंगित करने योग्य है कि हमें यह तय करना होगा कि struct Foo ( crate :: foo :: Bar ) को हल करने के लिए किस तरह का तरीका है -- क्या यह (crate::foo::Bar) प्रकार का एक निजी क्षेत्र है या यह crate फ़ील्ड है प्रकार ::foo::Bar ?
  
  
  
  • मुझे ईमानदारी से यकीन नहीं है कि हम इसे आज के रूप में पार्स करते हैं
  
  

उत्तर: हम इसे एक पथ (खेल का मैदान ) के रूप में पार्स करते हैं।

ऐसा लगता है .. शायद मेरे लिए ठीक है, क्योंकि मुझे लगता है कि ::foo::bar पथ तेजी से दुर्लभ हो जाएंगे।

हम में से बहुत से लोग इसके बारे में सकारात्मक महसूस करते हैं लेकिन कीवर्ड की पसंद के बारे में संदेह है, और क्या यह क्रेट :: फू :: बार पथ के साथ संयुक्त होने पर भ्रम पैदा कर सकता है।

@nikomatsakis क्या हमें पकड़ने के लिए नोट्स या सारांश मिलते हैं? इस सूत्र के भीतर, मैंने अपनी कम से कम एक चिंता [0] पर चर्चा नहीं की है और न ही काउंटर प्रस्तावों पर अधिक चर्चा की है। हो सकता है [0] और कुछ अन्य पर विभिन्न आंतरिक धागों में चर्चा की गई हो, लेकिन यह बहुत कुछ है।

[0] एक समानांतर दृश्यता सिंटैक्स बनाकर pub(...) को अस्पष्टता में धकेलते हुए इस भावना के साथ कि हमें pub(...) को हटा देना चाहिए या गले लगा लेना चाहिए

@epage

@nikomatsakis क्या हमें पकड़ने के लिए नोट्स या सारांश मिलते हैं?

कोई खेद नहीं; हमने इस पर बहुत लंबे समय तक (अधिक से अधिक कुछ मिनट) चर्चा नहीं की और इसके बारे में कोई मीटिंग नोट नहीं लिखा।

@eddyb ने संक्षेप में my को एक छोटे और अधिक एर्गोनोमिक दृश्यता संशोधक के रूप में बताया।

मुझे लगता है कि मैंने कहा mine लेकिन my और भी छोटा है, प्यारा!
(रिकॉर्ड के लिए, मैं बैठक में आधा मजाक कर रहा था)

संपादित करें : यदि my टोकरा-स्थानीय है, तो क्या हम pub को our से बदल सकते हैं? उदाहरण:

our struct Foo(my FooImpl);

(रिकॉर्ड के लिए, मैं बैठक में आधा मजाक कर रहा था)
अगर my क्रेट-लोकल है, तो क्या हम pub को our से बदल सकते हैं?

पर्ल: चुटकुलों को हकीकत बनाना।
https://perldoc.perl.org/functions/my.html
https://perldoc.perl.org/functions/our.html

my अच्छा है (और पहले आया है), बात यह है कि यह local , internal , या जो कुछ भी (या में) के संबंध में कोई स्पष्ट नहीं है इसका मामला, जिसका ), जो पूरी समस्या है।

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

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

इस बीच pub(crate) दोनों समस्याओं को हल करता है - यह आपको बताता है कि यह एक दृश्यता संशोधक है, और यह आपको बताता है कि दायरा क्या है - लेकिन बदले में यह लंबा और अजीब है।

तो यह मूल रूप से विधेय का आकार है।

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

एफडब्ल्यूआईडब्ल्यू, मैं क्रेट-स्थानीय वस्तुओं के लिए our या my के साथ पूरी तरह से ठीक हूं।
our एक तीन-अक्षर वाला कीवर्ड है और pub ~ और पर्ल ~ के साथ अच्छी तरह से संरेखित है।
क्या समस्या यह है कि वे बहुत अनौपचारिक लगते हैं (मूल अंग्रेजी बोलने वालों के लिए?)?

लोग intern के बारे में कैसा महसूस करते हैं? यह crate से अधिक लंबा एक वर्ण है, लेकिन इसके अलावा मुझे लगता है कि यह रस्ट के लिए नए लोगों के लिए crate से अधिक सहज होगा और extern कीवर्ड के लिए कुछ अच्छी समरूपता है।

IMO our और my में local और internal जैसी ही कमजोरी है: वे अपने दायरे के बारे में बहुत स्पष्ट नहीं हैं। local विशेष रूप से काफी भ्रमित करने वाला है, क्योंकि यह दायरा स्थानीय चरों से मौलिक रूप से भिन्न होगा, जहां स्थानीय का अर्थ निजी से संलग्न दायरे में होगा, जो किसी आइटम के लिए मॉड्यूल होगा, टोकरा नहीं। मुझे internal थोड़ा अविशिष्ट लगता है। किस लिए आंतरिक? मॉड्यूल? प्रारूप? टोकरा? यह उन लोगों के लिए स्पष्ट हो सकता है जो उन भाषाओं से आते हैं जहां इसका उपयोग किया जाता है लेकिन यह जरूरी नहीं कि दूसरों के लिए हो। our और my और भी अस्पष्ट हैं। इसके विपरीत crate दायरे के बारे में बहुत स्पष्ट है।

pub(extern) के संबंध में, मेरे पास वास्तव में एक प्रश्न है। क्या यह कभी भी extern "C" fn foo() {} pub के बिना होने का कोई मतलब है? क्योंकि यदि नहीं, तो हम अपने नियमित, गैर "सी" अबी रस्ट कार्यों के लिए भी extern fn foo() {} पुन: उपयोग कर सकते हैं। मैं सोच रहा था कि हम इसे एकीकृत कर सकते हैं और बाहरी वाक्यविन्यास को एफएफआई के लिए विशेष नहीं रख सकते हैं। इसका मतलब यह होगा कि extern अब desugars pub(extern) , pub आज की तरह ही रहता है लेकिन जब आइटम इसका समर्थन करता है तो एक वैकल्पिक एबीआई स्ट्रिंग स्वीकार करता है, और pub के लिए एक लिंट स्वीकार करता है pub(extern) या extern के निर्यात किए जा रहे हैं।

extern fn foo() {
    println!("Just called a Rust function from Rust!");
}

#[no_mangle]
extern "C" fn foo_from_c() {
    println!("Just called a Rust function from C!");
}

मैंने यह नहीं देखा है कि मैंने जो धागे पढ़े हैं उनमें उल्लेख किया गया है, अगर इस पर पहले चर्चा की गई है तो क्षमा करें!

क्या सामने पब के बिना extern "C" fn foo() {} होने का कोई मतलब है?

हां- कभी-कभी आप केवल foo का उपयोग फ़ंक्शन पॉइंटर के रूप में करना चाहते हैं, उदाहरण के लिए। और वास्तव में सिंटैक्स extern fn foo() {} को इसके लिए पुन: उपयोग नहीं किया जा सकता है क्योंकि extern बिना "C" सी एबीआई के लिए डिफ़ॉल्ट है, और इसे कम से कम कुछ लोगों द्वारा मुहावरेदार माना जाता है।

यहां एक सुझाव दिया गया है जो बहुत समय पहले आया था - शायद अब हम इसे एक और मौका दे सकते हैं कि नए मॉड्यूल सिस्टम के कुछ पहलुओं को क्रिस्टलीकृत कर दिया गया है?

// Public to the world.
pub struct Foo;

// Private to the crate.
priv struct Foo;

// Basically not visible at all (only inside the module).
struct Foo;

मेरा मानना ​​​​है कि यह समझ में आता है अगर कोई सोचता है:

• "सार्वजनिक" के रूप में "दुनिया के लिए सार्वजनिक"
• "निजी" के रूप में "टोकरा के लिए निजी"
• "कोई दृश्यता संशोधक नहीं" के रूप में "मूल रूप से बिल्कुल भी दिखाई नहीं दे रहा है"

priv सबसे अधिक प्रतिबंधात्मक नहीं होने पर कुछ लोगों की घुटने-झटके की प्रतिक्रिया थी, लेकिन मैं इसके बारे में दो बिंदु बनाना चाहता हूं:

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

2. मुझे लगता है कि जावा ने private की गलती की है जिसका अर्थ है "कक्षा के लिए निजी" और कोई दृश्यता संशोधक नहीं है जिसका अर्थ है "पैकेज के अंदर दृश्यमान"। मेरे लिए, यह सबसे अधिक प्रतिबंधात्मक होने के लिए कोई संशोधक (यानी डिफ़ॉल्ट) के लिए अधिक समझ में आता है।

@stjepang मैं तर्क दूंगा कि अधिकांश अन्य परिस्थितियों में "निजी" का एक असम्बद्ध राज्य की तुलना में अधिक प्रतिबंधात्मक अर्थ होने वाला है। निजी-डिफ़ॉल्ट-सार्वजनिक स्पेक्ट्रम सामान्य अर्थों में संरक्षित-उपलब्ध-विज्ञापित के समान है।

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

एक अनुभवहीन भाषा सीखने वाले के रूप में, मैं यह भी सुझाव दूंगा कि एक अतिरिक्त कीवर्ड कई संदर्भ-निर्भर अर्थों वाले एकल कीवर्ड की तुलना में एक संज्ञानात्मक बोझ से कम है। देखें कॉस्टेलो, एल और एबॉट, बी "हू इज ऑन फर्स्ट", 1938।

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

मुझे ईमानदारी से लगता है कि लोग सीखेंगे कि crate दृश्यता का क्या अर्थ है। मुझे लगता है कि बड़ी समस्या कोड से आती है जिसे पढ़ना मुश्किल हो जाता है या पार्स करने के लिए अस्पष्ट हो जाता है:

crate struct S(crate crate::Foo);

crate struct S(crate ::Foo);

मैं व्यक्तिगत रूप से उन्हें शोस्टॉपर के रूप में नहीं देखता, लेकिन वे निश्चित रूप से यहां वैध चिंताएं हैं।

स्कैला भाषा में pub(path) का समानांतर है, जो private[path] है, जो काफी समान कार्य करता है। यह थोड़ा अलग तरीके से पढ़ता है, "यह आइटम निजी है, केवल लोगों को $path के भीतर इसे देखने की इजाजत देता है"। लेकिन स्काला में कुछ निजी बनाने के लिए एक एनोटेशन की आवश्यकता होती है, क्योंकि डिफ़ॉल्ट सार्वजनिक होता है, जो कि रस्ट में नहीं होता है।

मेरे साथ ऐसा होता है कि friend s की C++ अवधारणा भी उदाहरण के एक अन्य बिंदु के रूप में pub(path) के समान है।

अंत में, मुद्दे हैं:

1. crate कीवर्ड का उपयोग सापेक्ष पथ आयात और दृश्यता संशोधक दोनों के लिए किया जाता है,
2. crate कीवर्ड pub(...) जैसे एकीकृत दृश्यता संशोधक सिंटैक्स को रोकता है,
3. कुछ pub(crate) सिंटैक्स को नापसंद करते हैं (बहुत लंबा, फ़ंक्शन कॉल जैसा दिखता है)।

वास्तव में गहरी सोच के 5 मिनट के बाद, मैं निम्नलिखित के साथ आया... :P

दृश्यता संशोधक के लिए विशेष सिंटैक्स

_(उदाहरण के तौर पर @ का उपयोग करते हुए)_

<strong i="18">@pub</strong> use crate::Foo;

<strong i="19">@crate</strong> struct Bar;

मुझे व्यक्तिगत रूप से यह काफी बदसूरत लगता है और मैं या तो @crate या pub(crate) टाइप नहीं करना चाहूंगा।

विशिष्ट दृश्यता संशोधक कीवर्ड

चूंकि पहले से ही नंगे pub और extern हैं, मुझे लगता है कि crate कीवर्ड काफी अच्छी तरह से फिट बैठता है (सामान्य public , protected के साथ भाषाओं से आने पर आश्चर्यजनक नहीं है private कीवर्ड)।

crate struct Foo;

crate fn path() -> PathBuf { ... }

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

use crate::utils;

ऐसा लगता है कि crate का कोई विशेष अर्थ नहीं है।

घोषणात्मक मैक्रोज़ सिंटैक्स से बड़ी प्रेरणा के साथ, दृश्यता संशोधक के लिए किसी प्रकार का एकीकृत वाक्यविन्यास खोजने के बजाय, मेरे पास निम्न होगा:

use std::io;
use std::path::Path;

use log::info;

use $crate::utils;

crate fn hello() -> io::Result<()> {
    utils::rm_rf(Path::new("/"))?;
    info!("Goodbye, World!");
}

( self , super और crate पथ आयात के लिए विशेष एंकरों को एक उपसर्ग की आवश्यकता होगी, उदाहरण के लिए, $crate , जो यह स्पष्ट करता है कि वे विशेष हैं और चर की तरह देखो)

जटिल उदाहरण:

crate struct Foo(crate crate::Bar);

बन जाता है:

crate struct Foo(crate $crate::Bar);

ऐसा प्रतीत होता है कि कोई डुप्लिकेट ट्रैकिंग समस्या है: https://github.com/rust-lang/rust/issues/45388 ।
उसी के पक्ष में उसे बंद करना।

क्या कोई कारण है कि रस्टसी कार्यान्वयन इस सुविधा को डॉगफूड कर रहा है? crate fn pub(crate) fn बदला जा सकता है और अस्थिर सुविधा AFAICT पर भरोसा करना बंद कर सकता है।

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

इस मामले में, crate का उपयोग Clippy और rustc में दृश्यता संशोधक के रूप में मेरे विचार में यह दर्शाता है कि यह pub(crate) से बेहतर पढ़ता है और इस ट्रैकिंग मुद्दे में संदर्भित अधिकांश मुद्दे गैर हैं - व्यवहार में मुद्दे। मुझे लगता है कि https://github.com/rust-lang/rust/issues/53120#issuecomment -413466129, https://github.com/rust-lang/rust/issues/53120#issuecomment -414392549, और https:/ /github.com/rust-lang/rust/issues/53120#issuecomment -413498376 यह भी सुझाव देता है कि दृश्यता संशोधक के रूप में crate बाहर भी अच्छी तरह से काम करता है।

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

एफडब्ल्यूआईडब्ल्यू, मैं इस सुविधा का उपयोग कार्गो-एन 64 में करता हूं और यह बहुत अच्छा रहा है!

मैं हर समय rustc में crate का उपयोग करता हूं क्योंकि यह छोटा है और इसमें pub(crate) जैसे कोष्ठक नहीं हैं।
मुझे अभी भी यह पसंद नहीं है कि यह कैसे पढ़ता है।
इसमें 3 अक्षर भी नहीं होते हैं, इसलिए pub <-> crate परिवर्तनों के साथ स्वरूपण परिवर्तन एक साथ होते हैं।
मुझे अब भी our एकतरफा पसंद है।

@petrochenkov आपने जो लिखा है उसकी मेरी समझ यह है कि आप crate को pub(crate) से अधिक पसंद करते हैं लेकिन crate से भी बेहतर कुछ चाहते हैं। क्या यह सही आकलन है?

एफडब्ल्यूआईडब्ल्यू, मुझे अभी भी लगता है कि intern एक अच्छा विकल्प है।

• कोई कोष्ठक नहीं
• pub(crate) से छोटा (हालांकि एक वर्ण crate से अधिक लंबा है)
• crate से बेहतर (IMO) पढ़ता है (जिसका उपयोग पथ जैसी अन्य चीजों के लिए किया जाता है, जैसे crate::foo::bar )
  
  
  
  • https://github.com/rust-lang/rust/issues/53120#issuecomment -411025646
  
  
• मौजूदा extern . के साथ अच्छी समरूपता है
• परिचित, जैसा कि अन्य भाषाएं कुछ इसी तरह का उपयोग करती हैं ( internal )। कोटलिन, सी #, आदि।

कहा जा रहा है, मैं यह भी मानता हूं कि pub(crate) को कुछ से बदला जाना चाहिए।

ठीक है तो यह तय हो गया है-- तीन अक्षर अच्छे हैं, और "इंटर्न" अच्छा है, इसलिए... int । ;)

क्या हम कृपया crate ::T (एक स्थान के साथ) मामले के लिए एक लिंट प्राप्त कर सकते हैं?

@Centril हम में से कुछ #rocket पर आगे के रास्ते पर चर्चा कर रहे थे। आपके हाल के-ईश टिप्पणी के आधार पर, क्या एक प्रस्तावित की संभावना है FCP निकट भविष्य में?

@jhpratt मैं एक राइट-अप करने का मतलब रखता हूं और आखिरकार इसे प्रस्तावित करता हूं लेकिन मैं अन्य चीजों में व्यस्त हूं। मैं निकट भविष्य में कुछ समय निकालने का प्रयास करूंगा।

तो, मैं सिर्फ मुद्दों को ब्राउज़ कर रहा था, मैक्रोज़ के बारे में कुछ ढूंढ रहा था, और यह पाया।

अब जबकि हमारे पास pub(crate) लंबे समय से स्थिर है, मुझे आश्चर्य है, क्या इस मुद्दे को बंद नहीं किया जाना चाहिए?

दिलचस्प बात यह है कि यह हाल ही में एक लैंग-टीम बैठक में सामने आया, जहां इस पर एक संभावित मुद्दे के रूप में चर्चा की गई जिसे हम पुनर्जीवित करना चाहते हैं।

व्यक्तिगत रूप से बोलते हुए, मैं निश्चित रूप से फ़ील्ड और उस तरह की चीज़ों पर crate fn और crate foo: T लिखने में सक्षम होने से चूक जाता हूं। यह pub(crate) से एक बड़ा वाक्य रचनात्मक अंतर नहीं है, लेकिन मुझे लगता है कि यह कोड को और अधिक पठनीय बनाता है, खासकर उन संरचनाओं में जिनमें बहुत सारे सार्वजनिक क्षेत्र हैं। मुझे यह भी लगता है कि यह एक उचित सहायक, सरलीकृत "गोपनीयता मॉडल" में योगदान देता है -

• structs, फ़ील्ड या तो एक मॉड्यूल के लिए स्थानीय हैं (बहुत संकीर्ण तर्क)
• या वे वर्तमान टोकरे के भीतर कहीं उपयोग किए जाते हैं ( crate , चारों ओर चीर-फाड़ करनी होगी)
• या वे दुनिया के लिए सार्वजनिक हैं ( pub )

मेरे विचार में, इस कीवर्ड और https://github.com/rust-lang/rust/issues/48054 में परिकल्पित परिवर्तनों के बीच कुछ अंतर है, और मैं यह सुनिश्चित करना पसंद करूंगा कि हम उन्हें एक साथ अपनाएं। मैं विवरण भूल जाता हूं लेकिन मुझे याद है कि उपरोक्त मॉडल को व्यवहार में लाने की कोशिश में त्रुटियां थीं।

मुझे लगता है कि इस दिशा में पहला कदम यह होगा कि कोई व्यक्ति इतिहास का दस्तावेजीकरण करने की कोशिश करे और यह सुनिश्चित करे कि हमने उन सभी चिंताओं को उजागर किया है जो उठाई गई थीं।

एक विशिष्ट चिंता जो मुझे याद है वह है वाक्यात्मक अस्पष्टता

struct Foo(crate ::x)

आज, यह स्वीकार किया जाता है और crate ::x पथ crate::x के रूप में पार्स करता है, लेकिन संभवतः उपयोगकर्ता का मतलब crate पथ के रूप में ::x के साथ दृश्यता संशोधक के रूप में कार्य करना था .

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

यदि हम संभावित उपयोगकर्ता-भ्रम को दूर करना चाहते हैं, तो मुझे लगता है कि एक व्हाइटस्पेस-संवेदनशील लिंट एक उचित विचार है। दूसरे शब्दों में, struct Foo(crate ::x) चेतावनी देगा, लेकिन struct Foo(crate::x) नहीं होगा, हालांकि ये दोनों स्वीकृत और समकक्ष हैं।

व्यक्तिगत रूप से, मैं एकीकृत वाक्यविन्यास और सरल लुकहेड (1) पार्सर अधिक पसंद करता हूं; इसके अलावा, एक टोकरा एक टोकरा होता है, और वहाँ पर crates.io होता है, और उन सभी चीजों का दृश्यता _directly_ से कोई लेना-देना नहीं होता है - केवल pub(_) के संदर्भ में।

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

@nikomatsakis जिज्ञासु यदि आपके पास इस उपयोग के मामले के लिए intern पर कोई विचार था (या इस बिंदु पर एक नए कीवर्ड को दायरे से बाहर कर रहा है?)

कुछ वर्षों के बाद, मेरी भावना अभी भी वही है: पठनीयता के लिए अनुकूलित करें। मुझे लगता है कि मैं कोड को लिखने से कहीं अधिक पढ़ता हूं। और इसलिए, मेरी राय यह है कि मेरे लिए pub(scope) पढ़ना अधिक स्पष्ट है, जो pub , pub(crate) , pub(super) , pub(in proto::h1) हो सकता है। .

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

मुझे यह भी लगता है कि यह एक उचित सहायक, सरलीकृत "गोपनीयता मॉडल" में योगदान देता है -

• structs, फ़ील्ड या तो एक मॉड्यूल के लिए स्थानीय हैं (बहुत संकीर्ण तर्क)
• या वे वर्तमान टोकरे के भीतर कहीं उपयोग किए जाते हैं ( crate , चारों ओर चीर-फाड़ करनी होगी)
• या वे दुनिया के लिए सार्वजनिक हैं ( pub )

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

मुझे लगता है कि pub(super) को पदावनत करना एक महत्वपूर्ण नुकसान होगा।

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

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

एक छोटी सी नई जानकारी:

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

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

इस मुद्दे की संपूर्णता को जल्दी से देखने से, मुझे लगता है कि @nikomatsakis की हालिया टिप्पणी चीजों को बहुत अच्छी तरह से बताती है। intern जैसी चीजों का समर्थन करने वाले कुछ चुनिंदा लोगों के अलावा, crate सबसे तार्किक लगता है (और RFC 2126 में स्वीकार किया गया था)। एकमात्र सही मायने में बकाया मुद्दा यह है कि fn foo(crate ::bar) को कैसे पार्स किया जाए।

एक चेतावनी-दर-डिफ़ॉल्ट व्हाइटस्पेस-संवेदनशील लिंट शुरू करने के लिए सबसे तार्किक स्थान लगता है। crate ::bar को वर्तमान में एक पथ के रूप में पार्स किया गया है, और रस्ट 2015 और 2018 दोनों में ऐसा ही रहना होगा। मैं कल्पना करता हूं कि यह एक संस्करण में एक ब्रेकिंग बदलाव के लिए एक उम्मीदवार होगा।

crate ::bar मामला व्यवहार में पूरी तरह से महत्वहीन है और पहले से ही बाकी भाषा के साथ लगातार व्यवहार करता है। यह लगातार चर्चा का केंद्र रहा है, कृपया इस पर ध्यान न दें।

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

मुझे लगता है कि मैं अस्वीकृति के लिए वोट दूंगा।
मैं rustc में pub(crate) $ के बजाय लगातार crate का उपयोग कर रहा हूं और छोटा होने के बावजूद यह अभी भी ज्यादातर समय से बाहर दिखता है, खासकर खेतों या आयात पर, और crate के बीच चयन करना pub(crate) ऐसा लगता है कि दो बुराइयों के बीच चयन करना है जबकि यह सुनिश्चित नहीं है कि कौन सी कम है।

हां। जो अधिक महत्वपूर्ण है, वह यह है कि @SimonSapin ने उल्लेख किया है कि crate bar वास्तव में एक नए टोकरे को परिभाषित नहीं करता है, इसके बावजूद यह पढ़ता है जैसे कि यह करता है।

@petrochenkov आपको नहीं लगता कि एक लिंट समझ में आता है? व्यक्तिगत रूप से, अगर मैंने इस चर्चा को देखे बिना crate ::bar देखा, तो मुझे उम्मीद है कि यह pub(crate) ::bar जैसा व्यवहार करेगा। मुझे लगता है कि _at all_ पथों में व्हॉट्सएप की अनुमति देना भ्रमित करने वाला है।

@jhpratt पथ खंडों के बीच सफेद जगह को अस्वीकार करना मुश्किल होगा, क्योंकि पार्सर्स टोकन के साथ कैसे काम करते हैं इसकी प्रकृति के कारण। इसके अलावा यह उद्धरण !, syn और कई अन्य जैसे उपकरणों की पागल राशि को तोड़ देगा।

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

यह "बड़ा" (लेकिन बंद) ट्रैकिंग समस्या #44660 में बेहतर फिट हो सकता है, लेकिन यह सीधे दृश्यता संशोधक से संबंधित है और #44660 के अन्य उप-मुद्दों में फिट नहीं है:

किसी बिंदु पर मुझे याद है कि किसी ने सुझाव दिया था कि pub(path) अब कानूनी हो सकता है, pub(in path) फॉर्म को बदलकर और pub(crate) और pub(super) शामिल कर सकता है। यह pub(...) का एक अच्छा सरलीकरण प्रतीत होता है, हालांकि crate से भिन्न दिशा में, जिस पर हम विचार भी कर सकते हैं।

संपादित करें: वास्तव में यह सुनिश्चित नहीं है कि यह काम करता है ... struct S(pub(path) Type) अस्पष्ट है (एलएल-एस्क पार्सिंग के लिए) struct S(pub (Type,)) जैसी चीजों के साथ।

इसलिए मैं पिछले कुछ महीनों से यही सोच रहा हूं। मुझे लगता है कि मैं "करीब" स्थिति में आ गया हूं। मुझे लगता है कि मेरी स्थिति का सारांश इस प्रकार है:

• "दृश्यता के तीन स्तर" (मॉड्यूल, टोकरा, दुनिया) का विचार अपेक्षाकृत सरल है, जो आकर्षक है, लेकिन यह सामान्य वास्तविक दुनिया के मामलों को याद नहीं करता है। pub(super) , विशेष रूप से, मुझे अभ्यास में वास्तव में काफी सामान्य लगता है, हालांकि एक से अधिक स्तरों की आवश्यकता होती है (यानी, pub(crate::foo) )। उदाहरण के लिए, मैं अक्सर ऐसे मॉड्यूल रखना चाहता हूं जिनमें उप-मॉड्यूल हों, और उन विवरणों के लिए टोकरा दृश्यता का उपयोग करना गोपनीयता के इच्छित स्तर को संप्रेषित करने में विफल रहता है।
• "टोकरा के कुछ हिस्से के लिए स्थानीय, या दुनिया के लिए सार्वजनिक" का मॉडल भी अवधारणात्मक रूप से सरल और सुरुचिपूर्ण है, और इसमें उन सभी उपयोग मामलों को शामिल किया गया है।
• pub(crate) fn , जबकि केवल crate fn की तुलना में काफी कम संक्षिप्त है, इतना बुरा नहीं है। यह प्यारा है कि pub(crate) तक विस्तारित है pub(crate::foo) , जो मुझे कभी-कभी मिलने वाले अन्य उपयोग के मामले को कवर करता है (यानी, एक टोकरा के भीतर "बड़ा" मॉड्यूल), लेकिन यह इतना क्रियात्मक है मुझे संदेह है कि यह शायद ही कभी होगा इस्तेमाल किया जा सकता है, और काफी संभावना है कि उन बड़े मॉड्यूल वैसे भी सबक्रेट्स में फैले हुए बेहतर होंगे ...
• मुझे लगता है कि "गोपनीयता के मिश्रित स्तर" के आसपास सबसे बड़ी एर्गोनोमिक बाधाएं लिंट्स और त्रुटियों से आई हैं जो यह सुनिश्चित करने की कोशिश कर रही हैं कि (उदाहरण के लिए) pub(x) fn में दिखाई देने वाले सभी प्रकार उपयुक्त गोपनीयता के थे। हमने उन नियमों को बदल दिया है और मुझे ऐसा लगता है कि मैं अब उन झुंझलाहटों को नहीं झेल रहा हूं - और अगर ऐसी और झुंझलाहट सामने आती है, तो मुझे लगता है कि हम उन्हें भी संबोधित कर सकते हैं।
  
  
  
  • उदाहरण के लिए, फ़ील्ड पर pub लिखना संभव है जिसका अर्थ है "संरचना के रूप में सार्वजनिक रूप से", और मुझे लगता है कि यह ठीक काम करता है।
  
  

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

संक्षेप में, मैं संकलक से crate दृश्यता स्तर को हटाने और फीचर गेट को हटाने के पक्ष में हूं।

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

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

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

क्या इसका मतलब यह है कि हम "पहुंच योग्य पब" लिंट ( mod private { pub fn f() {} } ) को भी सक्षम नहीं करते हैं?

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

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

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

संक्षेप में, मैं संकलक से crate दृश्यता स्तर को हटाने और फीचर गेट को हटाने के पक्ष में हूं।

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

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

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