Rust: डिफ़ॉल्ट तर्क और कीवर्ड तर्क

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

fn foo(bar: int, qux=2: int, ham=0: uint) { ... }

जिसे तब foo(1) , foo(1, 3) , foo(1, ham=4) , foo(6, 7, 8) , आदि कहा जा सकता है।

संपादित करें: कृपया नीचे huonw का प्रस्तावित वाक्यविन्यास देखें, जो वर्तमान घोषणा वाक्यविन्यास के साथ बहुत बेहतर और अधिक समान दिखता है।

ट्राइएज 2013-08-05: कोई प्रगति नहीं (जो मुझे पता है), हालांकि यह अभी भी साफ-सुथरी होगी; शायद घोषणा वाक्य रचना की तरह दिख सकता है

fn foo(bar: int, qux: int = 4, ham: Option<int> = None) { ... }

जहां आरएचएस कोई स्थिर एक्सपीआर है (यानी चीजें जो static घोषणा में मान्य हैं)।

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

क्या यह पहले निर्दिष्ट तर्कों और सामान्य प्रकार के मापदंडों के संदर्भ में अभिव्यक्तियों के रूप में लागू करने के लिए व्यवहार्य/उपयोगी होगा (उदाहरण के लिए .. शून्य देखने की क्षमता ::), या ऐसी चीज़ें लिखें जैसे स्लाइस(&self, start:uint , end:uint=self.len ()) /* "foobarbaz.slice(6) == "baz" .. or create_window(parent,x,y, width :uint=parent.width ()/4, ऊंचाई:uint= (चौड़ाई_161)/100) /_ डिफ़ॉल्ट गोल्डन-अनुपात आकार की विंडो है, और 1/4 स्क्रीन चौड़ाई यदि आप कोई आकार निर्दिष्ट नहीं करते हैं .. */ .. .. या यह कोड ब्लोट के लिए एक नुस्खा की तरह लगता है ..

सी ++ शैली डिफ़ॉल्ट हैकेल-जैसे आंशिक functoin-अनुप्रयोग को रोक देगा, लेकिन मैंने सुना है कि इसमें जाने की संभावना नहीं थी?

डिफ़ॉल्ट तर्कों के लिए यहां एक और विचार है। तर्कों को पूरी तरह से समाप्त करने की अनुमति देने के बजाय, हम उन तर्कों की अनुमति देते हैं जिनके लिए _ साथ एक डिफ़ॉल्ट मौजूद है।

तो दिया गया @huonw का प्यारा उदाहरण:

fn foo(bar: int, qux: int = 4, ham: Option<int> = None) { ... }

...हम इसे foo(1, 2, None) , foo(1, _, Some(1)) , foo(1, _, _) , आदि के रूप में लागू कर सकते हैं।

हालांकि, यह विचार कीवर्ड तर्कों को अपनाने के लिए वास्तव में कोई लाभ प्रदान नहीं करेगा, यह देखते हुए कि यह अभी भी सख्ती से स्थित है।

शीर्षक को "डिफ़ॉल्ट तर्क और कीवर्ड तर्क" में बदलना।

लागू नहीं किया गया, लेकिन मैंने ast & parser में जोड़ने का प्रयास किया; https://github.com/dobkeratops/rust/compare/default_args , क्या यह इसके बारे में जाने का सही तरीका है? (विकल्प @expr .. इसे expr क्या हो सकता है, इस पर बाधाओं की आवश्यकता होगी?)
इस विशेषता के साथ प्रयोग करने के लिए अपने पैर की उंगलियों को पानी में डुबोना।
मैं इस पर सी ++ एपीआई के सबसेट को बढ़ाने के लिए उत्सुक हूं जिसका अनुवाद किया जा सकता है, और वे निश्चित रूप से कुछ हैं जो मुझे सी ++ से याद आती हैं, और नामित कीवर्ड फीचर सी ++ के मुकाबले बहुत बढ़िया होगा।
दूसरे सुझाए गए डिक्लेरेशन सिंटैक्स के साथ जाना सरल और तार्किक लग रहा था

@dobkeratops जो अच्छा दिखता है (हालांकि type Default = Option<@expr> शायद अनावश्यक है)।

expr पर बाधाएं rustc::middle::check_const ; आपको check_fn जैसे फ़ंक्शन को जोड़ना होगा जो प्रत्येक तर्क की जांच करता है। (साथ ही, संभावित रूप से एक चेक होना चाहिए कि डिफ़ॉल्ट तर्क केवल अंत में दिखाई देते हैं; और मुझे लगता है कि टाइप-चेकर में कुछ होना चाहिए rustc::middle::typeck , और trans भी। )

ठीक है, फ़ील्ड का नाम इसलिए रखा गया है ताकि वह अन-नेसेरी एनोटेशन हो।
पॉइंटर्स के लिए धन्यवाद कि कहां देखना है, मैं rustc::middle::typeck::.. mod.rs (check_fn some ) में देख रहा था।

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

यह केवल विनाशकारी है यदि आप निश्चित रूप से उनके खिलाफ_ निर्णय लेते हैं?

किसी ने सुझाव दिया कि इस तरह की चीज -Z विकल्प (..Session::debug_opts... के साथ जा सकती है ...

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

@dobkeratops ध्यान दें कि अभी तक किसी भी आधिकारिक डेवलपर ने इस पर टिप्पणी नहीं की है, इसलिए यह बहुत कम संभावना है कि कोई पीआर स्वीकार किया जाएगा। यहाँ 1 के बारे में बहुत सारी चर्चा होनी चाहिए) क्या हम डिफ़ॉल्ट तर्क चाहते हैं, 2) यदि हां, तो वाक्यविन्यास क्या होना चाहिए, और 3) क्या हम कीवर्ड तर्क चाहते हैं (क्योंकि जो शब्दार्थ हम डिफ़ॉल्ट तर्कों के लिए चुनते हैं, वे इसे रोक सकते हैं) )

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

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

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

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

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

पूर्व के लिए, हम एक ही परिणाम (हालांकि श्रमसाध्य कार्यान्वयन लागत पर) को पूरा करने के लिए मैक्रो-हैकरी से दूर होने में सक्षम हो सकते हैं। वास्तव में, fmt!() लिए आगामी प्रतिस्थापन यह करता है:

ifmt!("{foo} {1} {bar} {0}", 0, 1, foo=2, bar=3)

यह कोड है जो आज काम करता है।

उत्तरार्द्ध के लिए, हमारे पास सबसे अच्छा एनालॉग निम्नलिखित के अनुसार कार्यात्मक संरचना अद्यतन का उपयोग करना होगा:

struct Foo { x: int, y: int, z: int }

impl Foo {
    fn default() -> Foo {
        Foo{x: 0, y: 0, z: 0}
    }
}

fn bar(f: Foo) {
    printf!(f);
}

fn main() {
    bar(Foo{y: 5, ..Foo::default()});
}

मैंने देखा है इस विधि तुरत-फुरत शेर कहकर डिफ़ॉल्ट तर्क की कमी के लिए एक समाधान के रूप में अतीत में सुझाव दिया है, लेकिन यह व्यवहार में काफी कुरूप है (तुलना bar(Foo{y: 5, ..Foo::default()}) करने के लिए bar(y=5) , या मेरे से अधिक रूढ़िवादी प्रस्ताव bar(_, 5, _) ), और निश्चित रूप से यह सभी कॉलर्स को एक स्ट्रक्चर बनाने के लिए मजबूर करता है, भले ही वे _do_ सभी तर्कों को पारित करना चाहते हों।

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

[1] https://groups.google.com/d/msg/golang-nuts/NWMReL1HueQ/X9mdYduCOB8J

[2] http://stackoverflow.com/questions/2032149/Optional-parameters

मुझे यह भी बताना चाहिए कि यह क्लोजर के साथ इंटरैक्ट करता है और कार्यों के लिए प्रथम श्रेणी के संदर्भ लेता है।

@bstree गो के अवलोकन के लिए धन्यवाद। मैं इस बात से सहमत हूं कि ओवरलोडिंग शायद एक बुरा विचार है क्योंकि यह भ्रमित करने वाले एपीआई बनाता है। इसी प्रकार jQuery की "ओवरलोडेड" विधियां जो आपके इच्छित किसी भी तर्क में कॉलबैक ले सकती हैं, वे बहुत अजीब हैं और लागू करने में दर्द होता है।

और मैं इस बात से सहमत हूं कि कुछ मामलों में डिफ़ॉल्ट तर्क भरने के लिए रैपर फ़ंक्शन इतने खराब नहीं होते हैं। लेकिन समस्या यह है कि जब यह आपको कुछ भ्रमित करने वाले मामलों से बचाता है, तो यह दूसरों में बहुत सारे बॉयलरप्लेट पेश करता है। एक उदाहरण *::to_str_radix(num, radix) । अगर हमारे पास वैकल्पिक आर्ग्स होते तो इसे *::to_str(num, radix = 10) में अच्छी तरह से फोल्ड किया जा सकता था। मुझे लगता है कि कुछ मामलों में फ़ंक्शन वेरिएंट का विस्फोट वास्तव में चीजों को कम सहज और याद रखने में कठिन बना देता है। बस मेरे दो सेंट हालांकि जाहिर है।

मैं उन्हें स्थगित करने के लिए एक अच्छा समय व्यापार-बंद देख सकता हूं;
लेकिन क्या _really_ दार्शनिक रूप से चूक को छोड़ देता है, या यह कि वे केवल उनके द्वारा किए गए कार्यान्वयन समय-बजट व्यापार-बंदों को सही ठहराते हैं? मुझे आश्चर्य होगा अगर किसी ने सोचा कि long_function_names_with_lots_of_trailing_qualifiers के माध्यम से वैडिंग एक कदम आगे है :), लेकिन अगर उन्होंने कहा "यह हमें सरल टूल का लाभ उठाने देता है, तो हमने अभी तक एक शक्तिशाली आईडीई विकसित नहीं किया है .." एक और बात है।

मैं निश्चित रूप से सी ++ से ओवरलोडिंग और डिफॉल्ट दोनों को याद करता हूं .. लेकिन मुझे रस्ट के अन्य विश्वासों और सी ++ विकल्प के वादे के लिए व्यापार करने में खुशी हुई है (इतने लंबे समय तक 1 मुख्य भाषा के साथ फंसने के बाद ..)

एक प्रयोग के लिए मैंने उन्हें 'पार्सर हैक' के रूप में करने की कोशिश करने के बारे में सोचा ... मैक्रोज़ के स्तर पर काम कर रहे हैं? डिफ़ॉल्ट एक्सपीआर को कॉल साइट्स पर इनलाइन करना जहां तर्क गुम हैं?
मुझे एहसास है कि यह एक स्वीकार्य डिजाइन होने की संभावना नहीं है - लेकिन यह मुझे _impossible_ नहीं डिफ़ॉल्ट तर्क देता है जो कि जंग की विशेषताओं के साथ काम करता है।

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

बस इसलिए विचार गायब नहीं होता है: bar(Foo{y: 5, ..Foo::default()}) का चतुर पहलू मुझे ..Foo::default() हिस्सा लगता है।

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

उदाहरण के लिए, एक नया रूप, शायद पूरी तरह से उन संरचनाओं के लिए परिभाषित किया गया है जो कुछ उपयुक्त विशेषता ( Zero या Default या जो कुछ भी) लागू करते हैं, जो इस तरह दिखता है:

Foo{y: 5, *) जहां * पहले ..Foo::default() की जगह लेता है।

फिर उदाहरण "बस" bar(Foo{y: 5, *}) । हो सकता है कि अन्य लोग Foo न करें, लेकिन यह मुझे बहुत साफ लगता है।

मुझे लगता है कि एनम आपको वैकल्पिक पैरा के समूहों को अलग-अलग तरीके से पारित करने के कुछ अन्य तरीके भी देते हैं जो एक सी ++ प्रोग्रामर के लिए उपयोग किया जाता है ... और एक कॉल के साथ एनोटेशन और मूल्यों को जोड़ने का एक तरीका।
ऐसा लगता है कि बहुत सारे सेटअप पैरामीटर के साथ कुछ बनाने जैसे मामलों के अनुरूप होगा

@pnkfelix याद रखें कि उस उदाहरण में Foo संरचना का शायद अधिक आत्म-वर्णनात्मक नाम होगा, और यहां तक ​​​​कि आपकी प्रस्तावित चीनी के साथ व्यवहार में ऐसा कुछ दिखाई देगा:

html::start_server(html::ServerOpts{port: 10088, *});

यह थोड़ा अच्छा लगता है। अभी भी निश्चित नहीं है कि यह नए सिंटैक्स को वारंट करने में पर्याप्त मदद करता है, या यदि यह डिफ़ॉल्ट तर्कों के सभी उपयोग मामलों को पूरा करने के लिए पर्याप्त है।

वास्तव में, अपने स्वयं के उदाहरण का उपयोग करने के लिए, जब एक HTML सर्वर जैसे बहुत सारे विकल्पों के साथ कुछ शुरू करना मैं शायद पहले से ही server_opts संरचना स्थापित करने और फिर start_server(server_opts) कॉल करने में उतना ही खुश हूं ..html::ServerOpts::default साथ एक पंक्ति जोड़ने में कोई फर्क नहीं पड़ता है यदि मेरी संरचना प्रारंभिक पहले से ही कई पंक्तियों तक फैली हुई है।

मुझे लगता है कि शायद हमें पुनर्विचार करने की जरूरत है जहां डिफ़ॉल्ट तर्क सबसे उपयोगी होंगे। मेरे लिए, यह वह जगह नहीं है जहाँ बहुत सारे संभावित तर्क हैं; ये काफी दुर्लभ होने चाहिए, और कॉन्फ़िगरेशन संरचना में प्रवेश करने के लिए कुछ पंक्तियां ठीक हैं। इसके बजाय, मुझे सबसे अधिक डिफ़ॉल्ट तर्क याद आते हैं जब 1) ऑपरेशन काफी सामान्य होता है, और 2) ऑपरेशन में, एक या दो तर्क होते हैं जो लगभग हमेशा अनावश्यक होते हैं लेकिन पूर्णता के लिए आवश्यक होते हैं। उदाहरण के लिए:

let foo = Some('a');
foo.unwrap();  // same as today
foo.unwrap('z');  // imagine that this replaced unwrap_or_default

int::from_str("4");  // same as today
int::from_str("4", 16);  // imagine that this replaced from_str_radix

हालाँकि, अब जब मैंने इन्हें टाइप कर लिया है, तो मैं वास्तव में अलग-अलग तरीकों की खोज करना पसंद करता हूँ। :) शायद मैं वास्तव में नहीं जानता कि मुझे क्या चाहिए!

@dobkeratops , सी ++ के साथ आपके अनुभव से, क्या आप हमें अच्छे सी ++ एपीआई के कुछ उदाहरण दे सकते हैं जो डिफ़ॉल्ट तर्कों द्वारा सक्षम हैं?

https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-08-13 में टिप्पणियों से संकेत मिलता है कि देव इसे एक दूर-भविष्य की विशेषता के रूप में देखते हैं। मनोनीत करना।

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

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

मैं सहमत हूं कि डिफ़ॉल्ट तर्क और/या कीवर्ड तर्क अत्यंत उपयोगी होंगे। मुझे लगता है कि हमें 1.0 से पहले के प्रस्ताव की दिशा में काम करना चाहिए जो यह बताता है कि ओवरलोडिंग के मामले में क्या किया जाना चाहिए और शायद वाक्य रचना पर चर्चा हो।

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

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

यही कारण है कि मैं इसे एएसटी डेटा-स्ट्रक्चर में पार्स करने पर आधारभूत कार्य जमा करना चाहता था। यह किसी और के लिए इसे लेने और समाधान निकालने का प्रयास करने के लिए तैयार होगा। प्रारंभिक प्रतिक्रिया ने मुझे पीआर बनाने से हतोत्साहित किया।

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

मुश्किल बिट टाइप चेकर है, सूक्ष्म बग संभावनाओं को रोकना और त्रुटियों को भ्रमित करना अगर यह सिर्फ एक पार्सर हैक के रूप में किया गया था, ऐसा लगता है।

कल्पना कीजिए कि क्या आप इस तरह की चीजें लिख सकते हैं ..

fn substr(a:&str, start:int, end:int=a.len())->~str

त्रुटि जांच के बिना एएसटी में उस तरह की चीज को हैक करें, मुझे यकीन है कि बहुत कुछ गलत हो सकता है .. लेकिन कल्पना करें कि क्या हम इसे ठीक करने के लिए ठीक कर सकते हैं :)

बस एक बग। हम गुण-दोष पर बहस कर सकते हैं, लेकिन इस पर रिलीज को रोक नहीं सकते।

मुझे वह व्यवहार पसंद है जो @tautologico ने अपनी टिप्पणी में वर्णित किया है।

जंग के लिए लागू, मेरा मानना ​​​​है कि यह निम्नलिखित में अनुवाद करेगा:

fn ga(bu: int, zo: Option<int>, meu: Option<int>) {
  let zo = zo.get_or_default(42);
  let meu = meu.get_or_default(99);
  ...
}

और ये सभी वैध कॉल होंगे:

ga(10, 20, 30); // 20 and 30 are automagically
                // converted to Some(20) and Some(30)
ga(10, 20);         // ga(10, 20, 99) 
ga(10);             // ga(10, 42, 99)
ga(10, None, None); // ga(10, 42, 99)
ga(10, 20, None);   // ga(10, 20, 99)
ga(10, None, 30);   // ga(10, 42, 30)

नियम यह है कि पिछला Option<T> पैरामीटर छोड़ा जा सकता है। यहां, Option प्रकार का पुन: उपयोग किया जाता है, लेकिन अगर इससे कुछ समस्याएं होती हैं तो एक और विशिष्ट OptParam प्रकार बनाया जा सकता है।

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

GUI संवाद बॉक्स दिखाने वाले फ़ंक्शन का वास्तविक जीवन उदाहरण:

fn showDialog(message: ~str,
              parent: Option<Widget>,
              title: Option<~str>,
              type: Option<DialogType>,
              icon: Option<Icon>) { ... }

// Display an info box in the middle of the screen.
// Set the title to "information", translated in the current locale
// Set the icon to an "info" icon
showDialog(~"hello, world!");

// Display a warning box in the middle of the screen.
// Set the title to "warning", translated in the current locale
// Set the icon to a "warning" icon
showDialog(~"sick, sad world!", None, None, WarningDialog);

// Display a warning box in the middle of the screen.
// Set the title to "warning", translated in the current locale
// Set the icon to a custom icon
showDialog(~"sick, sad world!", None, None, WarningDialog, bugIcon);

इस उदाहरण में:

• parent का डिफ़ॉल्ट मान None (कोई अभिभावक नहीं)
• type का डिफ़ॉल्ट मान InfoDialog
• का डिफ़ॉल्ट मान icon के मूल्य पर निर्भर करता है type
• का डिफ़ॉल्ट मान title के मूल्य पर निर्भर करता है type और वर्तमान स्थान पर

अब आप Option को एक नए आदिम प्रकार के रूप में जोड़ने का भी प्रस्ताव कर रहे हैं। यह अभी पूरी तरह से एक पुस्तकालय सुविधा है, क्योंकि यह एक सादा पुराना enum ।

मैं यह जोड़ना चाहता हूं कि IMO डिफ़ॉल्ट args कीवर्ड args के साथ एक अरब गुना बेहतर है। मुझे डिफ़ॉल्ट तर्कों का विचार पसंद नहीं है लेकिन कोई कीवर्ड तर्क नहीं है।

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

स्थितीय तर्कों के लिए डिफ़ॉल्ट मान गुप्त कोड में परिणत होते हैं। क्यों न केवल कीवर्ड तर्कों के लिए डिफ़ॉल्ट हैं? (यदि इन्हें लागू किया जाता है)।

आईएमओ ... यह "या तो-या" नहीं है।
वे दोनों उपयोगी हैं। वाक्य रचना में बनाने के लिए कम विकल्पों के साथ एक को लागू करना आसान है;
तो यह हमारे लिए समझ में आता है कि हम इसके लिए, या पहले इसे लागू करने का प्रयास करें, एक कदम पत्थर के रूप में...

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

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

यह निश्चित रूप से सामान्य रूप से सच नहीं है: एक के पास अक्सर कुछ तर्क होते हैं जिनकी आवश्यकता होती है और अन्य जो वैकल्पिक होते हैं।

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

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

struct Foo { x: int = 0, y:int = 0, z:int = 0 }

fn bar(f: Foo) {
    printf!(f);
}

struct Baz { x: int, y: int, z:int = 0 }

fn quux(g: Baz} {
    printf!(g);
}

fn main() {
    bar(Foo{y: 5});
    quux(Baz{y: 5}); // ~ERROR: required field, `x`
}

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

fn bar({ x: int = 0, y:int = 0, z:int = 0 }) {
    printf!(f);
}

fn quux({ x: int, y: int, z:int = 0 }) {
    printf!(g);
}

fn main() {
    bar({ y: 5 });
    quux({ y: 5 }); // ~ERROR: required field, `x`
}

@visionmedia @bstree क्या हमें वास्तव में संरचना नाम से छुटकारा पाने के बारे में चिंतित होने की आवश्यकता है? क्या रिबाइंडिंग उपयोग घोषणा कॉल-साइट पर अतिरिक्त वर्णों की न्यूनतम संख्या को 3 (नाम + बाएँ और दाएँ कोष्ठक के लिए) से कम करके, लंबे नामों की समस्या का समाधान नहीं करती है?

यानी, ServerOpts उदाहरण के साथ कि bstree ने मुझे बताया:

fn main() {
  use O = html::StartServerOptions;
  ...
  html::start_server(O{port: 10088});
}

@pnkfelix मुझे पसंद है

struct Foo {
   x: int = 10,
   y: float = 1.0
}

वाक्यविन्यास, लेकिन मुझे नहीं लगता कि हमें समझदार अनिवार्य तर्क प्राप्त करने की आवश्यकता है (दुर्भाग्य से नामित नहीं), बस अनिवार्य लोगों को अलग से पास करें:

struct FooOptions { ... }
static default: FooOptions = FooOptions { ... };
fn foo(compulsory: int, required: uint, necessary: float, optionals: FooOptions) { ... }

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

struct Test {
    m: int,
    y: int
}

static DEFAULT: Test = Test{m: 10, y: 15};

Test{y: 5, ..DEFAULT}

मुझे परिभाषा के अंदर भी संरचना डिफ़ॉल्ट पसंद है

मेरे पास उस वाक्यविन्यास के साथ पार्सिंग भी है लेकिन वास्तव में उपयोग नहीं किया गया है .. मुझे अभी भी टाइपचेकर स्रोत आदि के आसपास अपना रास्ता नहीं पता है ...

शायद तथ्य यह है कि पहले से ही एक डिफ़ॉल्ट तंत्र है जो इसे लागू करना थोड़ा आसान बना सकता है।

पुनः। अनाम संरचनाएं मुझे लगता है कि उनके पास मूल रूप से वे थे लेकिन उन्हें 'अजीब बातचीत के कारण' हटाना पड़ा?
मैं दोनों तंत्र उपलब्ध कराना पसंद करूंगा। शायद पैरामीटर स्ट्रक्चर्स _keyword_ तर्कों की आवश्यकता को कम कर देंगे, लेकिन सी ++ में अनुगामी चूक अभी भी आसान होगी

सन्दर्भ के लिए -
http://www.parashift.com/c++-faq-lite/named-parameter-idiom.html
योग्य - दिलचस्प लेकिन सही कीवर्ड तर्क इस तरह बॉयलरप्लेट भारी हैक्स की आवश्यकता से बचेंगे

पुनः। अनाम संरचनाएं मुझे लगता है कि उनके पास मूल रूप से वे थे लेकिन उन्हें 'अजीब बातचीत के कारण' हटाना पड़ा?

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

मुझे संरचना परिभाषा विचार में डिफ़ॉल्ट मान पसंद हैं। यह समझना आसान लगता है और कम से कम एक संरचना का निर्माण करते समय हर क्षेत्र की गणना करने से बचा जाता है - यह "विकल्प" प्रकार की संरचना के लिए एक समस्या है क्योंकि इसका मतलब है कि जब एक नया "वैकल्पिक" फ़ील्ड जोड़ा जाता है तो प्रत्येक कॉल साइट को संशोधित किया जाना चाहिए इसे 0/कोई नहीं/आदि में प्रारंभ करें।

पर्ल से आ रहा है (जहां डिफ़ॉल्ट एक एड-हॉक पैटर्न है), पायथन 2 (जहां आप foo() takes at least 2 arguments (2 given) प्राप्त कर सकते हैं), और पायथन 3 (जहां आपके पास केवल-नाम तर्क हो सकते हैं _without_ डिफ़ॉल्ट), मैं विनम्रतापूर्वक प्रस्ताव करता हूं: जोड़ें किसी फ़ंक्शन के लिए अंतिम तर्क के रूप में एक संरचना घोषित करने की अनुमति देने के लिए चीनी का एक _teeny_ बिट, लेकिन कॉलर को _inline_ संरचना फ़ील्ड दें।

जैसे

impl int {
    struct FromStrOptions {
        radix: uint = 10
    }
    fn from_str(s: str, opts: FromStrOptions) -> int {
        // ...
    }
}

int::from_str("4", radix: 10);

लाभ:

• फ़ंक्शन परिभाषा के लिए कोई नया सिंटैक्स नहीं है, जिसे वास्तव में इस बात की परवाह नहीं है कि कॉलर इसे कैसे कॉल करता है। यह उसी तरह है जैसे do साथ पासिंग ब्लॉक कैसे काम करता है: यह पूरी तरह से कॉलर की चिंता है। (क्या अंतिम तर्क के मामले में ऑप्ट इन/आउट करने का कोई तरीका होना चाहिए जो एक संरचना है लेकिन इसका इरादा नहीं है कि इसे kwargs के लिए उपयोग किया जाए? क्या कोई परवाह करेगा? मुझे नहीं लगता कि कोई भी do परवाह करता है
• बाइनरी लेआउट और सी कॉल सेमेन्टिक्स और इत्यादि अभी भी बहुत अच्छी तरह परिभाषित हैं।
• किसी दिन लागू करने के लिए प्रकार या एरिटी द्वारा ओवरलोडिंग अधिक कठिन नहीं है, सहेजें कि अंतिम तर्क का प्रकार ओवरलोडिंग टाइप करने में योगदान नहीं दे सकता है। विविध तर्कों में हस्तक्षेप नहीं करना चाहिए, या तो, यदि ऐसा कभी होता है।
• डिफ़ॉल्ट के एक ही सेट को कई कार्यों में पुन: उपयोग किया जा सकता है।
• मुफ्त में **kwargs जैसा कुछ: बस संरचना बनाएं और इसे इसके बजाय एक स्थितित्मक तर्क के रूप में पास करें।
• आवश्यक कीवर्ड तर्क स्वाभाविक रूप से इससे बाहर हो जाते हैं: बस संरचना में डिफ़ॉल्ट न दें, और आपको नाम से _something_ पास करने के लिए मजबूर होना पड़ता है।
• नाम से स्थितीय तर्क पारित करते समय कोई निराला भ्रम नहीं; तुम बस ऐसा नहीं कर सकते।

नुकसान:

• थोड़ा जादुई। लेकिन 5 और फ़ंक्शन के argspec से अनुमानित प्रकार होने के अलावा, मुझे लगता है।
• यह स्पष्ट नहीं है कि यह मौजूदा do मुहावरे के साथ कैसे इंटरैक्ट करेगा। यह कहना काफी आसान हो सकता है कि इसे अंतिम तर्क _लिखित_ होना चाहिए, यानी यह केवल दूसरे से अंतिम तर्क के रूप में काम करता है जब do साथ प्रयोग किया जाता है।

FWIW int::from_str("4", radix: 10) , पहले से प्रस्तावित, : के टाइप एस्क्रिप्शन ऑपरेटर के रूप में उपयोग के विरोध में होगा।

शाप, ASCII द्वारा विफल।

int::from_str("4", radix☃ 10)

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

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

हमने कल रात साप्ताहिक

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

टीम ने यह भी फैसला किया कि 1.0 रिलीज के लिए इसे किसी भी तरह से हल करना प्राथमिकता नहीं है। प्रोजेक्ट लीड @brson ने सुझाव दिया कि हम 1.0 के बाद के लिए इस कार्य पर कुछ भी प्रोटोटाइप करना छोड़ दें (उदाहरण के लिए 1.1 रिलीज के लिए)।

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

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

मुझे विस्तृत करने दो।

अच्छे API डिज़ाइन के लिए डिफ़ॉल्ट फ़ंक्शन तर्क _critical_ हैं; उनमें से कमी जटिल है कि अन्यथा सरल एपीआई क्या होगा। एसटीडी पुस्तकालय से उदाहरण:

• concat और connect बजाय केवल concat जो वैकल्पिक रूप से एक विभाजक लेता है।
• split_iter और splitn_iter केवल split_iter से अधिक एक वैकल्पिक count । rsplit_iter और rsplitn_iter ।

और दूसरे।

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

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

ताकि अतिरिक्त संज्ञानात्मक भार _हमेशा__ बना रहे।

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

रस्ट देव, रस्ट पर काम करने और इसे शानदार बनाने के लिए धन्यवाद!

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

https://github.com/mozilla/rust/issues?milestone=12&state=open

या माइलस्टोन 2 (पीछे की ओर-संगतता) पर 104 खुले बगों में से एक:

https://github.com/mozilla/rust/issues?milestone=13&state=open

या मील के पत्थर 3 पर 68 खुले बगों में से एक (एक बिंदु पर हम जिन सुविधाओं पर सहमत हुए थे, वे जंग 1.0 को जारी करने के लिए महत्वपूर्ण हैं):

https://github.com/mozilla/rust/issues?milestone=14&state=open

या यहां तक ​​कि स्पष्टीकरण मांगने या प्रगति करने के तरीके सुझाने के लिए उनमें से किसी एक बग पर टिप्पणी करें। इसमें से चुनने के लिए 213 बग हैं; इस समय उनमें से किसी एक पर प्रगति करना इस मुद्दे की तुलना में रस्ट के लिए अधिक मूल्यवान होगा। और जो कोई भी इन बगों में से किसी एक को बंद कर सकता है, उसके लिए हमारी अत्यधिक कृतज्ञता होगी।

मैं देख सकता हूं कि कोर टीम के पास करने के लिए और भी महत्वपूर्ण चीजें हैं लेकिन 'अत्यधिक निराशा का संचार' करना शर्म की बात है :(
वेलोरिक्स टिप्पणियों के लिए +1। नामकरण कठिन है, प्रलेखन के माध्यम से खुदाई करना और अधिक नाम सीखना अपमानजनक है..; डिफ़ॉल्ट आर्ग/ओवरलोडिंग इसे आसान बनाते हैं; कीवर्ड args के साथ आपको इस पर C++ से आगे जाने का अवसर मिलेगा। (काश जीथब के पास वोटिंग होती, मैं यहाँ थोड़ा और रेंट करने के बजाय सिर्फ +1 दबा सकता था)

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

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

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

यह 1.0 के लिए नहीं होने जा रहा है, क्योंकि बहुत ही अनावश्यक वाक्यात्मक चीनी का सपना देखने से पहले या तो ठीक करने या हटाने के लिए मूल भाषाओं की सुविधाओं का एक मौजूदा सेट है।

मैं यह नहीं कह रहा हूं कि अन्य भाषा विशेषताएं जिन्हें ठीक करने/कार्यान्वित करने की आवश्यकता है, वे अधिक महत्वपूर्ण नहीं हैं; वे शायद हैं। लेकिन यह या तो/या नहीं है। मैं केवल इतना कह रहा हूं कि 1.0 (अन्य सुविधाओं के अतिरिक्त) के लिए इस सुविधा पर दृढ़ता से विचार किया जाना चाहिए क्योंकि इसके नहीं होने से एसटीडी पुस्तकालय _forever_ में एपीआई की गुणवत्ता प्रभावित होती है।

यह शायद एक विवादास्पद राय है, लेकिन आईएमओ प्रोग्रामिंग भाषाएं उन एपीआई द्वारा अधिक जीवित और मर जाती हैं जो वे प्रदान करते हैं उनमें मुख्य विशेषताएं हैं। पायथन की "बैटरी शामिल" एसटीडी पुस्तकालय ने पूरी भाषा को बेच दिया। सीपीएएन पर्ल को जिंदा रखता है। .Net C# कोड को कमाल का बनाता है, और LINQ कटा हुआ ब्रेड के बाद से सबसे अच्छी चीज है। सी ++ की सबसे बड़ी विफलताओं में से एक अच्छे, मानकीकृत एपीआई की कमी है। आदि।

एपीआई एक भाषा की सफलता के लिए महत्वपूर्ण हैं, इसलिए _good_ एपीआई के निर्माण को सक्षम करने वाली सुविधाओं को "अनावश्यक वाक्यात्मक चीनी" के रूप में खारिज नहीं किया जाना चाहिए।

@dobkeratops : _dreaming up_ कहकर, मैं इस बात पर जोर देने की कोशिश कर रहा हूं कि कोई पूर्ण प्रस्ताव नहीं बनाया गया है, इसलिए यह निर्णय लेने के चरण में नहीं है

यह चर्चा अनुत्पादक है। इससे किसी का भी अधिक समय बर्बाद न हो, इसके लिए मैं इस मुद्दे को बंद करने जा रहा हूं। अगर कोई अब से एक साल बाद या उसके बाद इसे फिर से खोलना चाहता है (या एक नया मुद्दा शुरू करना चाहता है), तो यह ठीक रहेगा।

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

मैं दूसरा @thestinger - अगर किसी (या लोगों के एक छोटे समूह) के पास एक पूर्ण प्रस्ताव है, या कुछ स्पष्ट रूप से वर्तनी वाले रिक्त स्थानों के साथ एक प्रस्ताव है जो चर्चा के लिए है, तो उस व्यक्ति के लिए इसे चलाने के लिए उपयुक्त होगा मेलिंग सूची द्वारा। यह कोई वादा नहीं है कि हम उस प्रस्ताव को लागू करेंगे, लेकिन विचार को औपचारिक रूप देने का काम करने और यह समझाने के लिए कि यह अन्य भाषा सुविधाओं के साथ कैसे इंटरैक्ट करता है, सुझाव के मूल्य में काफी वृद्धि होगी।

@thestinger @catamorphism खुले दिमाग रखने के लिए आप दोनों को धन्यवाद! जब मुझे कुछ समय मिलेगा तो मैं एक प्रस्ताव तैयार कर रस्ट-देव को भेजूंगा।

मैंने इस सुविधा के बारे में बहस करने और इसके बारे में स्पष्ट विवरण लिखने के लिए एक पैड बनाया है: https://pad.riseup.net/p/hvbg6dQQnEe7

मैं इसे फिर से खोल रहा हूं। यह प्राथमिकता नहीं है - पहले से ही बहुत कुछ करने की आवश्यकता है - लेकिन यह एक ऐसी विशेषता है जो लोग चाहते हैं, और यह पूरी तरह से तालिका से बाहर नहीं है। मैं इस विषय पर किसी भी बातचीत को बंद नहीं करना चाहता।

@brson धन्यवाद!

मैंने मूल मुद्दे को ईथरपैड के लिंक के साथ संपादित किया है।

नमस्ते।
पैड निर्माण के बाद से, यह कई डिजाइन प्रस्तावों, प्रश्नों, समस्याओं आदि द्वारा पूरा किया गया है ...
इसलिए मैंने चर्चा पैड को "सारांशित" करने के लिए दूसरा पैड बनाया है, इस पैड का उपयोग सुविधा अनुरोध का सटीक वर्णन करने के लिए किया जाएगा।
यहां पैड यूआरएल: https://pad.riseup.net/p/Ca5PBeDjUGxW

@KokaKiwi अभी सारे पैड खाली हैं। सामग्री कहां गई?

@cmr , मुझे लगता है:

चेतावनी: यदि 30 दिन बिना किसी संपादन के बीत जाते हैं तो यह पैड हटा दिया जाएगा। ऐसा होने के बाद पैड को ठीक करने का कोई तरीका नहीं है, इसलिए सावधान रहें!

: भोंकना:

मैं वास्तव में मोज़िला ईथरपैड इंस्टेंस पर बनाए गए पैड को खोज रहा हूं (इस मामले को रोकने के लिए), लेकिन मैं इसे अपने इतिहास में नहीं ढूंढ सकता, और मैं यहां लिंक प्रकाशित करना भूल गया :(

@cmr @huonw @KokaKiwi , मेरे ब्राउज़र इतिहास में दो लिंक यहां दिए गए हैं:

https://etherpad.mozilla.org/CQEDa85jLX
https://etherpad.mozilla.org/78FA1bozLd

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

(संपादित।)

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

नई आरएफसी प्रक्रिया के माध्यम से एक ठोस प्रस्ताव किया जाना चाहिए: https://github.com/rust-lang/rfcs

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