शायद a..b| या a..b]

मुझे लगता है कि यह एक साधारण टाइपो (.. बनाम ...) के कारण भविष्य में नई तरह की अप्रत्याशित त्रुटियों के लिए रास्ता खोलेगा। बेहतर है अगर यह .... (4 अवधि)। इस तरह यह मानव कारक, आईएमओ के लिए कम त्रुटि-प्रवण है।

मुझे लगता है कि https://github.com/rust-lang/rfcs/pull/1592 और https://github.com/rust-lang/rfcs/pull/1582 संयुक्त रूप से ..= का उपयोग करने के लिए एक मामला बनाते हैं इसके बजाय वाक्यविन्यास। जब तक कोई बड़े टपल के सामने टपल का विस्तार करने के लिए (head..., tail) से बेहतर सिंटैक्स के बारे में नहीं सोच सकता।

मुझे यह समस्या इसलिए मिली है क्योंकि मेरे कोड में _off-by-one- dot _ त्रुटि थी जब मैं विशेष श्रेणी का उपयोग करना चाहता था।

... सिंटैक्स के लिए। मुझे लगता है कि एक आसान-से-गलत सिंटैक्स होना जो एक-एक करके त्रुटियों का कारण बनता है, एक फुटगन होगा।

कार्यक्षमता हालांकि उपयोगी है, इसलिए मुझे इसे एक अलग सिंटैक्स के साथ प्राप्त करने में खुशी होगी, उदाहरण के लिए ..=

क्या इसके लिए वाक्यविन्यास एक खुला प्रश्न है? चूंकि ... पहले से ही मैच स्टेटमेंट में है,

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

मैं सी-लाइक फॉर लूप्स for i in 0..foo.len() के बराबर के लिए समावेशी श्रेणियों का बहुत उपयोग करता हूं जहां यह पूरी तरह से फिट बैठता है, इसलिए मैं इसे रहने के लिए पसंद करूंगा (मुझे इसकी आवश्यकता है, क्योंकि रस्ट के इटरेटर "1-आयामी" हैं और अक्सर 2D सरणियों या गैर-रैखिक पुनरावृत्ति के साथ उपयोग करने के लिए बहुत अजीब)।

समावेशी श्रेणियों के लिए अतिप्रवाह के साथ समस्या मूर्खतापूर्ण लगती है, लेकिन व्यवहार में मैं इस समस्या में कभी नहीं भागा, क्योंकि जंग usize अलावा किसी भी प्रकार के उपयोग के लिए परेशान है। यदि मैंने for i in 0..(len as usize) श्रेणी बनाते समय कास्ट नहीं किया, तो मुझे लूप के अंदर वैसे भी i as usize आधा दर्जन बार उपयोग करना होगा।

चूंकि यह सिंटैक्स अभी भी फीचर-गेटेड है, मुझे आशा है कि जहाज रवाना नहीं हुआ है।

यह देखते हुए कि स्विफ्ट समावेशी के लिए ... का उपयोग करता है और विशेष श्रेणियों के लिए ..< का उपयोग करता है, समावेशी के लिए ..= का उपयोग करना काफी उचित लगता है।

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

fn fizzbuzz_to(n: u32) {
    for n in 1..n + 1 {
        fizzbuzz(n);
    }
}

यूपी ? मैं

मैं a ..= b वाक्यविन्यास और सामान्यीकृत श्रेणियों के लिए एक आरएफसी लिखना चाहता हूं। मानक पुस्तकालय में इस तरह की श्रेणियों का प्रतिनिधित्व कैसे किया जाएगा, इस बारे में बात करने के लिए मैंने एक चर्चा सूत्र शुरू किया है।

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

मुझे अभी भी लगता है ... और .. काफी अच्छा था। आपके पास 1 वर्ण अंतर है, इसलिए +/- या x/y या जो भी हो, से गलती करना कठिन है।

चूंकि मैंने इसे पहले गलत समझा था (और इसलिए मेरी टिप्पणी हटा दी):

रस्ट की RFC प्रक्रिया के अनुसार, इस प्रस्ताव की पहले ही समीक्षा की जा चुकी है, चर्चा की जा चुकी है और RFC पुल अनुरोध 1192 में स्वीकृत किया जा चुका है। वर्तमान मुद्दा वहां पहले से तय किए गए कार्यों के कार्यान्वयन को ट्रैक करता है। चर्चा में कई बिंदु शामिल हैं जो लोग यहां उठा रहे हैं: वैकल्पिक वाक्यविन्यास (कोई नया वाक्यविन्यास नहीं), रूबी के समान ऑपरेटरों के विपरीत, आदि।

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

@jimblandy शायद हमारे पास @nikomatsakis उस विनम्र अनुस्मारक और मार्गदर्शन को वास्तव में बिग प्रिंट में पहली टिप्पणी में संपादित करना चाहिए। मैं

@shepmaster _all_ ट्रैकिंग समस्याओं को दर्ज करने के लिए उपयोग किए जाने वाले टेम्पलेट में जोड़ने के लिए शायद यह एक अच्छी बात होगी।

चर्चा के लिए नामांकन/संभावित FCP

हमने @rust-lang/lang बैठक में इस पर चर्चा की। इस विशेषता से नाखुश होने की एक सामान्य भावना थी - हमने इसे बहिष्कृत करने पर विचार किया, लेकिन कुछ समय के लिए उस पर रोक लगाने का निर्णय लिया। ... को लेकर दो प्रमुख आपत्तियां हैं:

• .. और ... बीच भ्रम की आसानी;
• @aturon सोच रहा है कि अधिक "पूरी तरह से सक्षम" रेंज सिंटैक्स होना बेहतर होगा - इसका उपयोग एपीआई में भी किया जा सकता है जैसे btree पुनरावृत्ति और आगे।

उस अंत तक, हम सोच रहे थे कि क्या कोई आरएफसी को आगे बढ़ाने के लिए तैयार होगा जो कि अधिक सामान्य वाक्यविन्यास को सक्षम करता है जिससे लोगों को यह स्पष्ट रूप से निर्दिष्ट किया जा सके कि निचली और ऊपरी सीमाएं समावेशी या अनन्य होंगी या नहीं। मुझे लगता है कि @aturon ऐसे RFC पर किसी के साथ काम करके खुश होगा।

मुझे पता है कि मैं थोड़ी देर के लिए रुक गया था, लेकिन मैंने हाल ही में libstd ( ऊपर लिंक) में उन पूरी तरह से सक्षम श्रेणियों का प्रतिनिधित्व करने के बारे में एक चर्चा सूत्र खोला, लेकिन किसी ने टिप्पणी नहीं की :(

ऊपर दिए गए कुछ इनपुट के साथ, मुझे एक नए RFC के साथ मदद करने में खुशी होगी।

मैंने हाल ही में libstd (ऊपर लिंक) में उन पूरी तरह से सक्षम श्रेणियों का प्रतिनिधित्व करने के तरीके के बारे में एक चर्चा सूत्र खोला है, लेकिन किसी ने टिप्पणी नहीं की :(

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

@दुर्का

मुझे पता है कि मैं थोड़ी देर के लिए रुक गया था, लेकिन मैंने libstd (ऊपर लिंक) में उन पूरी तरह से सक्षम श्रेणियों का प्रतिनिधित्व करने के तरीके के बारे में चर्चा सूत्र खोला, लेकिन किसी ने टिप्पणी नहीं की :(

ऐसा लगता है कि मोटे तौर पर हमारे मन में दृष्टिकोण था, हाँ।

@पेट्रोचेनकोव

जबकि मनमानी समावेशी-अनन्य श्रेणियां एक अच्छे विचार की तरह लगती हैं, मुझे पूरा यकीन है कि .. और बहुत कम डिग्री को छोड़कर सबकुछ कभी भी उपयोग नहीं किया जाएगा।

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

ऐसा लगता है कि मोटे तौर पर हमारे मन में दृष्टिकोण था, हाँ।

कौन - सा? मैंने अपनी पोस्ट में कई विकल्प सुझाए।

मैं अक्सर समावेशी पर्वतमाला से अधिक पुनरावृति करना चाहते हैं और वास्तव में टाइपिंग पसंद आया 0...x के बजाय 0..(x + 1) । मैं समझता हूं कि यह एक के बाद एक त्रुटियां पेश कर सकता है, लेकिन हमारे पास क्या विकल्प हैं?

यह मानते हुए कि रस्ट के सिंटैक्स को बिना किसी दुष्प्रभाव के स्वतंत्र रूप से बदला जा सकता है, मुझे केवल कुछ स्पष्ट पैटर्न दिखाई देते हैं:

इसे वैसे ही लेना

1..4 // 1, 2, 3
1...4 // 1, 2, 3, 4

जो एक ठीक समाधान IMHO है और पैटर्न-मिलान में भी उपयोग किया जाता है।

गणित से उधार लें

[1, 4] // 1, 2, 3, 4
[1, 4[ // 1, 2, 3
]1, 4] // 2, 3, 4
]1, 4[ // 2, 3

जो सबसे पूर्ण वाक्यविन्यास है, लेकिन ब्रेसिज़ नियम खोलने और बंद करने की समान मात्रा को तोड़ता है और पार्स करने के लिए दृष्टि से कठिन है।

पायथन से उधार लें

1:1:=5 // 1, 2, 3, 4, 5
1:1:<5 // 1, 2, 3, 4

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

जब स्टेपसाइज़ इस चर्चा (या भविष्य में) का हिस्सा नहीं है, तो ..= और ..< बहुत ही उचित लगते हैं!

अद्यतन: मुझे लगता है कि ..= और ..< वास्तव में एक अच्छा समाधान होगा। स्टेपसाइज़ को एडॉप्टर के रूप में रखने से बहुत अधिक समझ में आता है।

क्या इस चर्चा में अवरोही श्रेणी शामिल होनी चाहिए? रेंज को बदलने का वर्तमान समाधान काफी भ्रमित करने वाला है (लेकिन शायद ऐसा नहीं होगा अगर हमारे पास समावेशी श्रेणियां हों)।

उदाहरण के लिए क्या आप बिना भेंगापन किए इसे पढ़ और समझ सकते हैं?

for i in (1..l.len()).rev() { ... }

संपादित करें: और गिटहब के फ़ॉन्ट के साथ यह और भी भ्रमित है क्योंकि l 1 जैसा दिखता है

मुझे लगता है कि एक नकारात्मक कदम पर्याप्त होगा।

हम मैटलैब सिंटैक्स, a:b और a:step:b ।

नवंबर 4, वर्ष 2016 00:50 पर, "ओट" [email protected] लिखा है:

मुझे लगता है कि एक नकारात्मक कदम पर्याप्त होगा।

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

@durka तो वर्तमान .. के बराबर क्या होगा, जहां a या b ? बस : ?

कुछ ऐसा जो मैंने RFC में नोट नहीं देखा: क्या फ़ील्ड के लिए अलग-अलग नामों पर विचार किया गया था?

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

(यह निश्चित रूप से अप्रासंगिक है यदि रेंज के पक्ष में विभिन्न प्रकारों को छोड़ दिया जाता है>...)

मुझे लगता है कि समावेशी श्रेणी को अभी भी std::Collections::range::RangeArgument लागू करना चाहिए।

pub trait RangeArgument<T> {
    fn start(&self) -> Option<&T> { ... }
    fn end(&self) -> Option<&T> { ... }
}

फिर

impl RangeArgument<T> for RangeToInclusive<T> {
   fn end(&self) {
     Some(self.end+1)
   }
}

ताकि fn foo<T, R: RangeArgument<T>>(arg: R) समावेशी या अर्ध-खुली श्रेणियां ले सकें।

@durka ए: बी सिंटैक्स के साथ समस्या यह है कि यह टाइप शिलालेख के साथ संदिग्ध है। क्या आप एक चर b , या एक प्रकार b मांग रहे हैं? स्पष्ट रूप से अच्छे रस्ट प्रोग्रामर के रूप में हम अपने प्रकारों को कैपिटलाइज़ करते हैं, लेकिन कंपाइलर इसका अनुमान नहीं लगा सकते हैं।

.. गणित परिभाषाओं के साथ ऑपरेटर ( @dusee टिप्पणी के आधार पर):

[1..4] // 1, 2, 3, 4
[1..4[ // 1, 2, 3
]1..4] // 2, 3, 4
]1..4[ // 2, 3

उपयोग करना ( @0tt उदाहरण के आधार पर):

fn fizzbuzz_to(n: u32) {
    for n in [1..n + 1] {
        fizzbuzz(n);
    }
}

इस मामले में हम केवल संकेत के रूप में .. उपयोग करते हैं, लेकिन सीमाएं [ और ] द्वारा दी गई हैं

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

मुझे लगता है कि ..= समावेशी श्रेणियों के लिए सबसे उचित विकल्प है।
.. से नेत्रहीन अंतर करना आसान है, जो ... नहीं है। ... जब अर्थ .. या इसके विपरीत टाइप करने की संभावना ..= ।
(यह गलती से टाइप करने के लिए तुलनीय है if(a = b) के बजाय if(a == b) दृश्य noticeability और बग क्षमता में सी में, दोनों)।
और ..= याद रखना आसान है क्योंकि यह इसके अर्थ के लिए प्रतीकात्मक है ( i ..= j अर्थ है सीमा i .. j और जहां i = j )।

ऐसा लगता है कि प्रमुख शिकायत यह है कि ... बहुत हद तक .. । मैंने देखा कि जब अन्य सुझाव दिए जाते हैं जिनमें अधिक वर्ण शामिल होते हैं तो कोई भी वर्णों की संख्या के बारे में शिकायत नहीं करता है, केवल कुछ जगहों पर ब्रैकेट मिलान और उपयोग जैसी चीजें होती हैं।
तो, समावेशी श्रेणियों के लिए .... के बारे में क्या? यह अभी भी एक सीमा की तरह दिखना चाहिए, और जैसा कि मैंने कहा कि किसी को भी कोई समाधान नहीं लगता है जो एक अतिरिक्त चरित्र लेता है। यह बहस का विषय है कि क्या यह ..= से कम या ज्यादा जीतने वाला है।
for i in 0....10 { println!("just a thought"); }

यदि डिफ़ॉल्ट व्यवहार समावेशी थे ..! ऑपरेटर का उपयोग किया जाएगा (लगभग एक निषेध के रूप में)।

.... साथ समस्या यह है कि यदि ... वास्तव में मौजूद है तो कुछ भ्रम होगा।

मुझे वास्तव में ... नहीं है, क्योंकि रूबी से बिल्कुल उलटा है।

मुझे लगता है कि अब तक का सबसे अच्छा विकल्प ..= है।

@adelarsq, .... ऑपरेटर की जगह लेंगे ... तो ऑपरेटर, यदि आप करने की कोशिश की .. और एक अतिरिक्त जोड़ा . एक संकलन, यह होगा समय त्रुटि, यदि आपने .... और एक बिंदु भूल गए, तो यह भी एक त्रुटि होगी।

चूंकि पैटर्न मिलान में, ... का उपयोग समावेशी श्रेणी से मेल खाने के लिए किया जाता है, इसलिए समावेशी श्रेणी अभिव्यक्ति के लिए ... का भी उपयोग करना समझ में आता है।
चरण के साथ श्रेणी के लिए, मैं हास्केल सिंटैक्स पसंद करता हूं, उदाहरण के लिए 1,3..9 => [1,3,5,7]

स्टेप/रिवर्स, आदि के साथ श्रेणियों के लिए। मैं एक जटिल शाब्दिक के बजाय एक अच्छे पुराने जमाने के फ़ंक्शन (कुछ प्रकार का Range कंस्ट्रक्टर) पसंद करूंगा।

मैं क्वाड-डॉट .... साथ ठीक रहूंगा (हालांकि ..= IMHO भी ठीक है)। इसे पैटर्न मिलान में भी स्थिरता के लिए अनुमति दी जा सकती है (और अंततः पैटर्न में ... को बहिष्कृत किया जा सकता है)।

मेरे लिए ..= एक दृश्य संकेत के रूप में जो .... नहीं है।

मैंने अभी कुछ देखा:

गणित में आप ∀ i: 0 ≤ i < 10 लिख सकते हैं जिसका अनुवाद होगा

for i in 0 ..< 10 { }

यह सुसंगत है।

हालांकि, कथन ∀ i: 0 ≤ i ≤ 10 का अनुवाद होगा

for i in 0 ..= 10 { }

यहाँ, का अनुवाद = है, जो असंगत लगता है।

यह बाइक शेडिंग हो सकता है, लेकिन

for x in 0 ..<= 10 { }

अधिक सही लगता है। यह मेरी सी पृष्ठभूमि के कारण हो सकता है जहां

for (unsigned int i = 0; i <= 10; ++i) { }

"जब तक i छोटा है या 10 बराबर है, तब तक अनुवाद करता है"। सीआई में लूप स्थितियों में == का उपयोग नहीं करना पसंद करते हैं, क्योंकि मूल्य पर कूदने और अनंत लूप में समाप्त होने की संभावना है। रस्ट में ऐसा नहीं हो सकता है, लेकिन for i in 1 ..= 10 से C में अनुवाद करना ठीक यही सुझाव दे सकता है।

इसे और आगे ले जाना,

for i in 0 <..<= 10 { }

स्व-व्याख्यात्मक होगा।

संपादित करें: यहां एक खराब रिवर्स उदाहरण था जो यह दिखाने के लिए था कि केवल = का उपयोग कैसे भ्रमित हो सकता है। हटा दिया गया, क्योंकि यह रचनात्मक से अधिक भ्रमित करने वाला था।

@ड्यूसी >=..> स्व-व्याख्यात्मक कैसे है? क्या यह <=..> (<= 10 और > 0) नहीं होना चाहिए?
आईएमओ यह आत्म-व्याख्यात्मक नहीं है, यह गुप्त है और एक ऑपरेटर के रूप में बहुत लंबा है।
(कोई भी ऑपरेटर IMO 3 वर्णों से अधिक लंबा नहीं होना चाहिए)।
बीटीडब्ल्यू, हमारे पास पहले से ही रिवर्स पुनरावृत्ति दिशा व्यक्त करने का एक तरीका है: .rev()
हमें केवल समावेशी श्रेणियों और शायद .step_by() लिए ऑपरेटरों की आवश्यकता है।
चरण के लिए सिंटैक्स a .. b | s (और समावेशी श्रेणियों के लिए: a ..= b | s ) हो सकता है।

@norru : आपका उदाहरण for i in (1..l.len()).rev() { ... } बहुत अवास्तविक है, क्योंकि ज्यादातर समय आप स्लाइस ( for x in arr[1..].rev() { ... } ) का उपयोग करेंगे, लेकिन भले ही आपको पुनरावृत्ति की अनुक्रमणिका-शैली का उपयोग करने के लिए मजबूर किया जाए (मूल रूप से केवल जब आप सरणी तत्वों को संशोधित करते हैं जो i नहीं हैं), तो मुझे इसे पढ़ना बिल्कुल भी मुश्किल नहीं लगता। (लेकिन मैं आमतौर पर .. आसपास रिक्त स्थान छोड़ देता हूं जब तर्क शाब्दिक संख्या नहीं होते हैं: (1 .. arr.len()).rev() )

>=..> रस्ट ऑपरेटरों में मछली की अधिक प्रजातियां!

लेकिन मुझे ..<= बहुत पसंद है (संपादित करें: उह, match को छोड़कर जहां यह <= 0 => जैसा दिखता है :()

• यह सादे .. से बहुत अलग है,
• इसमें += अर्थ नहीं है ..= ,
• यह स्विफ्ट के ..< साथ भी तार्किक रूप से सुसंगत है। दोनों भाषाओं का अभिसरण संभव है!
• और सबसे महत्वपूर्ण बात यह है कि यह बहुत स्पष्ट है कि आपको सीमा में संख्याएं मिलती हैं जो ऊपरी से कम या उसके बराबर होती हैं।

@pornel : >=..> more species of fish in Rust operators! हे :-)

@ बॉस्कोप : यदि आप इसे गणित में परिभाषा की तरह पढ़ते हैं तो यह आत्म-व्याख्यात्मक है: 10 >= i > 2 । आपके शेष उत्तर के लिए: मैं बिल्कुल सहमत हूं। दूसरा भाग ..= बनाम ..<= पर पुनर्विचार करने की प्रेरणा के रूप में था क्योंकि भविष्य के विस्तार के लिए अवरोधकों को पेश नहीं किया गया था। मैं तदनुसार अपना उत्तर संपादित करूंगा।

.. नोटेशन पर चेतावनी या त्रुटि के लिए ध्वज भी प्राप्त कर सकते हैं

मैं नहीं चाहता कि .. मेरे कोडबेस में कहीं भी दिखाई दे

मैं ..= लिए एक और वोट देना चाहता हूं

..< और ..<= लिए नकारात्मक पक्ष यह है कि वे पहले से ही वैध कोड हैं (एक अन्य मूल्य की तुलना में एक सही-खुली अनन्य श्रेणी)।

@thepowersgang

..< और ..<= का नकारात्मक पक्ष यह है कि वे पहले से ही मान्य कोड हैं (एक राइट-ओपन एक्सक्लूसिव रेंज की तुलना दूसरे मान से की जा रही है)।

जबकि सच है, यह व्यवहार में एक समस्या होने की बहुत संभावना नहीं है, नहीं?

मैं यहां अन्य सुझावों के लिए ... को बहुत पसंद करता हूं .. लेकिन अगर मुझे एक वैकल्पिक वाक्यविन्यास चुनना पड़ा, तो यह ..=

@nikomatsakis

मैं ..< और ..<= विकल्पों के पूरी तरह से इस आधार पर खिलाफ हूं कि वे भाषा के व्याकरण के एक सहज मॉडल को प्राप्त करने की प्रक्रिया को असमान रूप से जटिल बनाते हैं।

अधिक व्यक्तिगत नोट पर, मैं उन्हें कम से कम बदसूरत और सुरुचिपूर्ण टर्बोफिश के रूप में पाता हूं।

मैं के साथ जाना चाहते हैं .. सही अनन्य के लिए और ..= समावेशी के लिए के रूप में दृश्य लालित्य के बीच सबसे अच्छा संतुलन, व्याकरण के नियमों सहज समझ करने के लिए आसान कर रहे हैं, और भ्रमित करने के लिए दो कठिन बना कि।

क्या ... वास्तव में .. ? मुझे यह इतना पसंद क्यों है?

@त्शेपांग

मुझे ... क्योंकि यह सौंदर्य की दृष्टि से आकर्षक है ... लेकिन मैं इसके खिलाफ तर्क देता हूं क्योंकि मुझे चिंता है कि इसमें if (x == 2) { बजाय if (x = 2) { लिखने के समान नोटिस-टू-नोटिस बग पैदा करने की क्षमता है। सी/सी++ में if (x == 2) { । (और यह अच्छी तरह से स्थापित है कि क्या खतरा निकला।)

@ssokolow

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

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

@ssokolow

मैं .. राइट-एक्सक्लूसिव और ..= समावेशी के लिए दृश्य लालित्य, व्याकरण नियमों के बीच सर्वोत्तम संतुलन के रूप में जाना चाहता हूं जो सहज रूप से समझने में आसान हैं, और दोनों को भ्रमित करना मुश्किल है।

इससे मेरा काम बनता है। मुख्य बात यह है कि क्या हम अन्य मामलों के लिए भी एक सिंटैक्स चाहते हैं (उदाहरण के लिए, <..<= )। मुझे व्यक्तिगत रूप से लगता है कि .. और ..= 99.5% मामलों की तरह कवर करता है। मुझे लगता है कि मुख्य उपयोग केस drain जैसे एपीआई हैं, और हमने वर्तमान में वहां एक

cc @rust-lang/libs

हम असामान्य मामलों को सीधे उपयोग करके श्रेणियों का निर्माण करने के लिए छोड़ सकते हैं
संरचना शाब्दिक।

बुध, 22 फरवरी, 2017 को शाम 4:50 बजे, निको मात्साकिस नोटिफिकेशन @github.com
लिखा था:

@ssokolow https://github.com/ssokolow

मैं साथ जाऊंगा .. राइट-एक्सक्लूसिव और ..= समावेशी के लिए सर्वश्रेष्ठ के रूप में
दृश्य लालित्य, व्याकरण के नियमों के बीच संतुलन जो सहज रूप से आसान हैं
समझना, और दोनों को भ्रमित करना कठिन बना देता है।

इससे मेरा काम बनता है। मुख्य बात यह है कि क्या हम भी चाहते हैं a
अन्य मामलों के लिए वाक्य रचना (जैसे, <..<=)। मुझे व्यक्तिगत रूप से लगता है कि .. और ..=
99.5% मामलों की तरह कवर। मुझे लगता है कि मुख्य उपयोग का मामला एपीआई जैसे नाली है,
और हमने वर्तमान में वहां एक अलग दृष्टिकोण अपनाया है
https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.range
.

cc @rust-lang/libs https://github.com/orgs/rust-lang/teams/libs

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

मुझे लगता है कि ..= पैटर्न में भी उपलब्ध कराया जाएगा? वहां मौजूदा ... सिंटैक्स का क्या होगा?

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

बुध, फ़रवरी 22, 2017 पर 6:02 प्रधानमंत्री andrewtj पर [email protected] लिखा है:

मैं इसे लेता हूँ..= पैटर्न में भी उपलब्ध कराया जाएगा? का क्या होगा
मौजूदा ... वाक्य रचना वहाँ?

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

@durka @andrewtj मुझे लगता है कि हम इसे हटा देंगे।

..= का उपयोग ऑपरेटर के रूप में += के समान अर्थ में किया जा सकता है।
मेरा सुझाव है कि ज्वार ~ , उदाहरण के लिए 0~9 , 'A'~'Z' ।

..= किस ऑपरेशन के अनुरूप होगा? - स्पष्ट रूप से अव्यवहार्य है क्योंकि
1-9 == -8 ।

बुधवार 22 फरवरी, 2017 को रात 8:04 बजे, जुनफेंग लियू नोटिफिकेशन @github.com
लिखा था:

..= का उपयोग ऑपरेटर के रूप में += के समान अर्थ में किया जा सकता है।
मेरा सुझाव है कि ~ का उपयोग करें, उदाहरण के लिए 0~9, 'ए'~'जेड'।

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

@durka ..= बस असाइनमेंट ऑपरेटर की तरह दिखते हैं, उपयोग का मामला दुर्लभ होना चाहिए। ~ ज्वार उप नहीं है। उपयोग ... भी ठीक है।

impl Fill for Range<String> {
   fn fill() -> String { ... }
}
impl FillAsign for RangeAssign<String> {
   fn fill(&mut self) { ... }
}
(String::new("abc") .. String::new("f")).fill()  // "abcdef"
(String::new("abc") ..= String::new("f")).fill()  //  ()

ओह क्षमा करें, यह मेरे फ़ॉन्ट में समान दिखता है। मैं पूछ रहा था, अगर ..= एक यौगिक है
असाइनमेंट ऑपरेटर जैसे +=, यह कौन सा ऑपरेशन करता है (संबंधित .)
से +)?

बुधवार 22 फरवरी, 2017 को रात 8:29 बजे, जुनफेंग लियू नोटिफिकेशन @github.com
लिखा था:

@durka https://github.com/durka ..= बस असाइनमेंट जैसा दिखता है
ऑपरेटरों, उपयोग का मामला दुर्लभ होना चाहिए। ~ ज्वार उप नहीं है।

सीमा के लिए भरें{
fn भरण () -> स्ट्रिंग {...}
}
रेंजअसाइन के लिए impl FillAsign{
fn भरें (और स्वयं म्यूट करें) {...}
}
(स्ट्रिंग :: नया ("एबीसी") .. स्ट्रिंग :: नया ("एफ"))। भरें () // "abcdef"
(स्ट्रिंग :: नया ("एबीसी") .. = स्ट्रिंग :: नया ("एफ"))। भरें () // ()

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

@durka @nikomatsakis ठीक है, मुझे आशा है कि यह जल्द ही हल हो जाएगा। वर्तमान स्थिति अजीब है और वाक्य रचना बदलना भी होगा।

@pornel ... को match पदावनत करने से संगतता टूट जाएगी, इसलिए यह एक अच्छा समाधान नहीं है। मुझे अभी भी ... सबसे पर्याप्त लगता है (हालांकि यह रूबी का सटीक उलटा है, लेकिन रूबीवादियों द्वारा इसी तरह की कोई समस्या पर चर्चा नहीं की गई है)।

@ hyst329 लेकिन ... त्रुटियों के प्रति अधिक संवेदनशील हो सकता है, क्योंकि लापता होने या एक . जोड़ने से एक नया अर्थ मिलेगा

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

लेकिन उपयोगकर्ताओं को दस्तावेज़ीकरण और rustfmt के माध्यम से नए सिंटैक्स की ओर ले जाया जा सकता है।

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

"कृपया जांचें कि आपका क्या मतलब है और .. या ..= " की नस में एक कंपाइलर चेतावनी, जिसे ऑटो-फिक्स नहीं किया जा सकता है, को कम करने के मौजूदा प्रयासों के अनुरूप बहुत अधिक होगा मानवीय भूल की संभावना।

कृपया ध्यान दें कि मैं पैटर्न में मौजूदा ... संदर्भ में बात कर रहा था, जहां कोई फ़ुटगन मौजूद नहीं है। वर्तमान में जंग एक अस्थायी फ़ुटगन-मुक्त स्थिति में है जहां पैटर्न केवल ... अनुमति देते हैं और अभिव्यक्ति केवल .. अनुमति देती है, इसलिए दोनों टाइपो से सुरक्षित हैं।

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

आह। मैं इसके बारे में भूल गया था। मुझे याद दिलाने के लिये धन्यवाद।

@adelarsq दरअसल, 'a'..'z' या 128u8..255u8 जैसी सामान्य त्रुटियों को आसानी से cargo-clippy में एकीकृत किया जा सकता है। और साथ ही, .. और ... की चौड़ाई स्पष्ट रूप से अलग है (जब मोनोस्पेस्ड फ़ॉन्ट का उपयोग करते हैं, तो इसका उपयोग नहीं करना आम तौर पर सामान्य रूप से स्रोत कोड लिखने के लिए एक बुरा विचार है - न केवल जंग) .

हम इसके लिए सिंटैक्स बना सकते हैं … बजाय ... (यूनिकोड क्षैतिज अंडाकार) इस तरह से कम से कम कोई भी इसे दुर्घटना से टाइप नहीं करेगा।

संपादित करें: ओह कोई भी लोग इस सुझाव को गंभीरता से नहीं ले रहे थे: रोना: शोर के लिए खेद है।

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

साथ ही, हर किसी के पास आसानी से लिखें टाइप करने के लिए कंपोज़ कुंजी नहीं होती है । . जब वे चाहते हैं …

विंडोज़ पर मैं numpad के साथ Alt + 0133 का उपयोग करके अंडाकार टाइप कर सकता हूं! …

और इसी तरह के कोडपॉइंट-आधारित तंत्र X11-आधारित डेस्कटॉप पर स्टैक की विभिन्न परतों पर मौजूद हैं (मुझे GTK+ और X11 इनपुट स्टैक के अपने स्वयं के स्वतंत्र समाधान याद हैं) लेकिन संख्या के आधार पर कोडपॉइंट याद रखना एक बड़ी परेशानी है।

लिखें एक सहज ज्ञान युक्त समाधान है।

मुझे याद है कि एकमात्र विंडोज़ Alt अनुक्रम Alt + 219 जो मैंने एक बच्चे के रूप में बनाए गए सभी डॉस बैच फ़ाइल मेनू से किया है।

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

वर्तमान सिंटैक्स को बनाए रखना सबसे खराब है जो हम कर सकते हैं क्योंकि इसके कई वास्तविक नुकसान हैं। यह सिर्फ बाइक शेडिंग नहीं है - इसे सही किया जाना चाहिए। पूरे धागे को छोड़कर, ..= सिंटैक्स को अब तक सबसे अधिक स्वीकृति मिली है...

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

या हम सचमुच दुनिया में कोई अन्य वाक्यविन्यास कर सकते हैं।

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

और मुझे व्यक्तिगत रूप से अंतर को पहचानने में कोई समस्या नहीं है, हालांकि मैं मानता हूं कि दृष्टि वाले लोग, या 4k मॉनिटर और 10pt फ़ॉन्ट के साथ, हो सकता है।

लेकिन ऐसा लगता है कि आम सहमति ..= और मुझे लगता है कि मैं इसके साथ भी ठीक हूं।

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

@rust-lang/lang चर्चा के लिए नामांकन। मुझे लगता है कि हमें सिर्फ ..= अपनाना चाहिए और इसे एक दिन कहना चाहिए। क्या हमें संशोधित RFC की आवश्यकता है? इसे कर ही डालो? क्या इसमें पैटर्न में मौजूदा ... सिंटैक्स को पदावनत करना शामिल है? (मैं ऐसा मानता हूं।)

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

..= स्पष्ट लगता है, और इसकी सापेक्ष कुरूपता .. से कम सामान्य होने के कारण उचित है।

क्या इसमें पैटर्न में मौजूदा ... सिंटैक्स को बहिष्कृत करना शामिल है? (मैं ऐसा मानता हूं।)

यह एक अच्छा विचार लगता है। ... पर चेतावनी दें और यदि संभव हो तो पैटर्न में .. और ..= दोनों का समर्थन करें।

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

मैं ... पक्ष में हूं क्योंकि यह अधिक "सामान्य" वाक्यविन्यास है; मैं ..= का उपयोग करने वाली किसी भी भाषा के बारे में नहीं जानता, लेकिन कई जो .. और ... ।

यदि ..= खिलाफ भावना मजबूत है, तो मैं दृश्य समस्या से बचने के लिए और फिर से मुक्त होने के लिए बिना किसी समावेशी श्रेणी वाक्यविन्यास (इसके बजाय (a..b).inclusive() विधि का चयन करना, जो मेरे लिए पर्याप्त संक्षिप्त लगता है) के साथ जाना पसंद करूंगा विविध जेनरिक के लिए ... ऊपर।

संपादित करें: (a..b).inclusive() खिलाफ एक अच्छा तर्क यह है कि हमारे पास अभी भी ... में match और दुर्भाग्य से इसे बदलने के लिए कोई नया सिंटैक्स नहीं होगा। :अस्पष्ट:

@steveklabnik क्षमा करें यदि यह पहले से ही इस (बहुत लंबे) धागे में कहीं उल्लेख किया गया है, लेकिन: अन्य भाषाएं क्रमशः अनन्य और समावेशी श्रेणियों के लिए .. और ... दोनों का उपयोग

जंग का अन्य भाषाओं से उपयोगी सुविधाओं और वाक्य-विन्यास को अपनाने का इतिहास है, लेकिन चुनिंदा रूप से , और जहां उपयुक्त हो वहां चीजों को अस्वीकार या अनुकूलित करना।

@joshtriplett रूबी दोनों का उपयोग करता है, लेकिन विपरीत अर्थों के साथ ( .. समावेशी है, ... अनन्य है)। मुझे विश्वास नहीं है कि रूबी में यह एक अच्छा विचार था, और ऐसा लगता है कि हमारे लिए दोनों के लिए और भी अधिक संभावित रूप से भ्रमित है, लेकिन पीछे की ओर।

@joshtriplett जिसे मैं सबसे ज्यादा परिचित हूं वह रूबी है; मैंने सोचा कि इसे पर्ल से मिला है लेकिन मुझे पूरा यकीन नहीं है। मैं ..= मुकाबले रूबी से पीछे की ओर अर्थशास्त्र के साथ अधिक ठीक हूं।

ईमानदारी से, मैं किसी भी चीज़ पर एक स्थिर समावेशी श्रेणी वाक्यविन्यास पसंद करूंगा, और यह मानता हूं कि ..= के

@steveklabnik स्विफ्ट ..< का उपयोग करता है, मुझे लगता है, है ना? जो ..= समान लगता है लेकिन इससे भी बदतर, इसमें यह (आईएमओ) गलत मामले के लिए अनुकूलन करता है। =)

स्विफ्ट उपयोग करता है ..< अनन्य के लिए और ... समावेशी के लिए (उनकी शर्तें हैं
"आधा खुला" और "बंद")।

मुझे अभी भी पसंद है ..< (साथ में .. शॉर्टहैंड के रूप में) और ..=।

लेकिन एक और खुला प्रश्न (शायद इस ट्रैकिंग मुद्दे के दायरे में नहीं है) यह है कि क्या हम बंद श्रेणियों के लिए "सिर्फ" सिंटैक्स अपनाते हैं, या पहले बिंदु के साथ श्रेणियों के लिए सिंटैक्स (वाक्यविन्यास?) >..=.

गुरु, मार्च 16, 2017 अपराह्न 2:19 बजे, निको मात्साकिस नोटिफिकेशन @github.com
लिखा था:

@steveklabnik https://github.com/steveklabnik स्विफ्ट का उपयोग करता है ..<, मुझे लगता है,
अधिकार? जो ..= के समान लगता है, लेकिन इससे भी बदतर, इसमें इसके लिए अनुकूलन होता है
(आईएमओ) गलत मामला। =)

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

मुझे प्रस्तावना में inclusive फ़ंक्शन होने पर कोई फर्क नहीं पड़ता:

for x in inclusive(1..10) {

}

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

मुझे लगता है कि ..= और ... साथ डाउनसाइड्स दोनों महत्वपूर्ण हैं - ..= काफी अजीब है, लेकिन ... 1 त्रुटियों से बंद होने की संभावना को बढ़ाता है।

बग के लिए इस तरह की कभी न खत्म होने वाली क्षमता की तुलना में एक अजीब दिखने वाला ऑपरेटर होना बेहतर है (हर भाषा उन ऑपरेटरों का परिचय देती है जो दूसरों के पास नहीं हैं, उदाहरण के लिए स्विफ्ट में ..< , एफ # और स्काला में सभी ऑप्स)। लोगों को वैसे भी रस्ट बुक पढ़नी होगी।
यह देखते हुए कि रूबी से बहुत सारे लोग जंग में आ रहे हैं, हमें रूबी की तुलना में इसे पीछे की ओर नहीं रखना चाहिए। (इस तर्क के अलावा कि ... 1 त्रुटियों से बंद होने की संभावना को बढ़ाता है।)
आप स्विफ्ट में ..< को कैसे स्वीकार कर सकते हैं लेकिन रस्ट में ..= को स्वीकार नहीं कर रहे हैं? ..= इतना अजीब नहीं है।

पैटर्न में रेंज सिंटैक्स का विस्तार करना अभी भी एक खुला प्रश्न है और साथ ही AFAIK भी है।
एक बात के लिए, हम इसे पूरी तरह से नहीं कर सकते, क्योंकि Enum::Variant(..) पहले से ही है
मान्य है और इसे बदलने का मतलब है Enum::Variant(RangeFull) तोड़ना होगा।

गुरु Mar 16, 2017 में 3:07 बजे पर, Boscop [email protected] लिखा है:

एक अजीब दिखने वाला ऑपरेटर होना बेहतर है (हर भाषा परिचय देती है
ऑपरेटर जो दूसरों के पास नहीं हैं, उदाहरण के लिए ..< स्विफ्ट में, एफ # में सभी ऑप्स
और स्काला)। लोगों को वैसे भी रस्ट बुक पढ़नी होगी।
यह देखते हुए कि रूबी से बहुत सारे लोग जंग में आ रहे हैं, हम
रूबी की तुलना में इसे पीछे की ओर नहीं होना चाहिए। (तर्क के अलावा
कि ... 1 त्रुटियों से बंद होने की संभावना बढ़ जाती है।)
आप स्विफ्ट में ..< को कैसे स्वीकार कर सकते हैं लेकिन रस्ट में ..= को स्वीकार नहीं कर रहे हैं?

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

इसलिए। मैं slice.get(10...30) जैसी चीजें टाइप करने में सक्षम होना चाहता हूं और अपना केक भी खा सकता हूं।

मैंने खुद को आश्वस्त किया है कि मैं किसी भी अन्य वाक्यविन्यास के लिए inclusive(0..10) को दृढ़ता से पसंद करता हूं:

• जबकि @nagisa slice.get(10...30) लिखना चाहती है, मैं इस बात पर पूरा ध्यान नहीं देना चाहता कि वह slice.get(10...30) या slice.get(10..30) । मुझे लगता है कि वाक्य रचना की निकटता एक वास्तविक समस्या है।
• मुझे लगता है कि हर कोई सहमत है कि ..= अनैच्छिक है और शायद सहज नहीं है।
• (0..10).inclusive() समान सिंटैक्स है लेकिन कम सुविधाजनक है। तकनीकी रूप से, inclusive प्रस्तावना शायद दोनों सिंटैक्स का समर्थन करेगी।

मुझे लगता है कि यह इस तरह दिखेगा:

trait IntoInclusive {
    type Inclusive;
    fn inclusive(self) -> Self::Inclusive;
}

fn inclusive<T: IntoInclusive>(range: T) -> T::IntoInclusive {
    range.inclusive()
}

मुझे लगता है कि हर कोई सहमत है ..= अनैच्छिक है और शायद अनजान है।

मुझे लगता है कि यह कहना थोड़ा अधिक सामान्यीकरण है। मुझे लगता है कि ..= inclusive() जैसी विधि की तुलना में अधिक सौंदर्यपूर्ण और सहज है।

(साथ ही, हम नहीं जानते कि ..= लिए कितनी नापसंदगी उन चीजों के साथ समस्याओं को खोजने के अवचेतन (या सचेत) प्रयास हो सकते हैं जो ... ।)

.inclusive() इतनी बार होने वाली किसी चीज़ के लिए बहुत लंबा है (उस नोट पर, मुझे यह भी लगता है कि .enumerate() लिए एक छोटा रूप होना चाहिए)।
लेकिन भले ही हमारे पास .inclusive() , केवल एक फ़ंक्शन होना चाहिए, दो नहीं।
इसके अतिरिक्त, कोई समावेशी श्रेणी सिंटैक्स नहीं होने से उन्हें match में उपयोग करने की अनुमति नहीं मिलेगी।
लेकिन शायद हमें सामान्य तरीके से निकालने वालों को निर्दिष्ट करने का एक तरीका चाहिए, जैसे स्कैला में ? ताकि मैच में किसी भी प्रकार का उपयोग किया जा सके, ताकि मैच परोक्ष रूप से इसकी unapply विधि को कॉल किया जा सके।

(साथ ही, हम यह भी नहीं जानते हैं कि ..= के लिए कितनी नापसंदगी उन चीजों के साथ समस्याओं को खोजने के अवचेतन (या सचेत) प्रयास हो सकते हैं जो नहीं हैं ....)

मुझसे कोई नहीं। यह एक तरह से दुर्भावना का आरोप है।

इसके अतिरिक्त, कोई समावेशी श्रेणी सिंटैक्स नहीं होने से उन्हें मिलान में उपयोग करने की अनुमति नहीं मिलेगी।

समावेशी श्रेणी पैटर्न पहले से ही match में समर्थित हैं। वास्तव में वे ही एकमात्र प्रकार की रेंज हैं जिनका हम आज पैटर्न के रूप में समर्थन करते हैं।

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

समावेशी: for i in 1..10! { }

किसी ऐसे व्यक्ति के रूप में जो जावा/सी/सी++ के साथ 15 वर्षों से अधिक काम करता है, मुझे लगता है कि .. बनाम ... बहुत भ्रमित करने वाला है और गलतियों को टाइप करने से बग का कारण बन सकता है। इसके अलावा रूबी के साथ संबंध इसे और भी भ्रमित कर देता है। इसलिए ..= या कोई अन्य विकल्प बेहतर है।

मेरी 'टोपी' को रिंग में फेंकना:

for i in 1..10^

टोपी/कैरेट इस बात का प्रतीक है कि सही मूल्य _up_ तक जाता है।

@leebenson व्यक्तिगत रूप से मुझे लगता है कि यह बेहतर होगा अगर यह बीच में हो, बाहर से नहीं।

for i in 1..^10

@ retep998 मैंने माना कि भेजने के बाद ... वास्तव में यह वास्तव में अच्छा है।

@ retep998 मैं अपने के सुझाव की तरह ..^ ज्यादा बेहतर की तुलना में ..= ; यह इसके अर्थ के बारे में अधिक स्पष्ट लगता है, और यह एक संवर्धित असाइनमेंट ऑपरेटर (जैसे += और *= ) के एक अजीब संस्करण की तरह दिखने से बचता है। उस ने कहा, कोई भी ... से कहीं बेहतर होगा।

मैं ..^ पीछे नहीं रह सकता।

व्यक्तिगत स्तर पर, मुझे यह बहुत बदसूरत लगता है (आंशिक रूप से क्योंकि .. कई फोंट में ^ से लंबवत रूप से अलग है)।

एक यूआई/यूएक्स लड़के के रूप में, मुझे लगता है कि यह आपके अपने अच्छे के लिए बहुत चालाक होने का एक उदाहरण है।

अगर मैं किसी अन्य भाषा से आता हूं और ..^ देखता हूं, तो मैं इसे एक सीमा के रूप में भी नहीं पहचान सकता (मुझे पता है कि 5..^15 15! - 4! लिए कुछ अजीब आंशिक फैक्टोरियल शॉर्टहैंड हो सकता है

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

इसके विपरीत, = में असाइनमेंट की कार्रवाई और समानता की अवधारणा दोनों को संदर्भित करने के लिए मिसाल है और ..= के लिए कोई "अजीब घातांक वाक्यविन्यास" जैसी गलत धारणा नहीं है क्योंकि आप " असाइनमेंट + समानता" जिसे पहले से असाइनमेंट ऑपरेटर द्वारा नियंत्रित नहीं किया गया है, "संख्याओं के अनुक्रम के साथ कुछ करना है, जो दाहिने हाथ पर समाप्त होता है" ...

मुझे यह भी चिंता है कि, भले ही मैंने यह पहचाना हो कि ..^ संदर्भ में इसके उपयोग से रेंज सिंटैक्स था, मुझे कोई सहज विचार नहीं होगा कि यह पहले समावेशी या अनन्य था, क्योंकि ^ लिए कोई अर्थ नहीं है 2..^8 दो से शुरू होने वाली ओपन-एंडेड रेंज के लिए शॉर्टहैंड है और पिछले चरण को 8 की शक्ति तक ले जाकर कदम उठा रहा है। (यानी 2..Inf^8 के विपरीत 2..+8 "8 के चरणों में 2 से अनंत तक पुनरावृति" के लिए आशुलिपि है।)

उस समस्या से भी बचा जाता है ..= क्योंकि लोग < (अनन्य) बनाम <= (समावेशी) के संदर्भ में सोचने के आदी हैं जब while लूप लिखते हैं और सी-स्टाइल for लूप।

@ssokolow कानूनी विश्लेषण।

व्यक्तिगत रूप से, मैं या तो पीछे रह सकता हूं ..= या ..^ । या तो की सहजीवन मेरे लिए समझ में आता है - यानी 'अप टू एंड इक्वल टू' या बस 'अप टू', क्रमशः। मेरे विचार से उन दोनों का एक ही अर्थ है।

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

किसी भी मामले में, मैं किसी फ़ंक्शन कॉल बनाम किसी रूप में शॉर्टहैंड नोटेशन पसंद करूंगा जो दाएं हाथ की वैल को स्पष्ट रूप से +1 करता है। मैं पहले की टिप्पणियों से सहमत हूं कि फ़ंक्शन कॉल की तरह महसूस करने वाली किसी चीज़ को सौंपने के लिए यह बहुत सामान्य वाक्यविन्यास है। मुझे कोई आपत्ति नहीं है ... , लेकिन दी गई, यह शायद नए कपड़ों में = / == बग है और पैर में किसी को गोली मारने के लिए बाध्य है ...

बहुत से लोग सक्रिय रूप से नापसंद करने लगते हैं ..= किसी ने कुछ भी नकारात्मक नहीं कहा
के बारे में .... इसे चुपचाप अनदेखा कर दिया गया था (कुछ अंगूठे को छोड़कर) I
सोचा था कि मैं इसे फिर से लाऊंगा और लोगों को इस पर विचार करने और देने के लिए कहूँगा
अगर वे इसके खिलाफ हैं तो इसका इस्तेमाल न करने का कारण।

मुझे इसका उल्लेख करने से भी नफरत है क्योंकि यह सिर्फ अधिक शोर है, लेकिन इसके बारे में क्या:
(डॉट कोलन) समावेशी के लिए? यह 3 बिंदु है लेकिन 2 वर्ण हैं, और मुझे लगता है कि
आकार इसे अलग बनाता है ..

शनिवार, 18 मार्च, 2017 को पूर्वाह्न 11:50 बजे, ली बेन्सन नोटिफिकेशन @github.com
लिखा था:

@ssokolow https://github.com/ssokolow कानूनी विश्लेषण।

व्यक्तिगत रूप से, मैं या तो ..= या ..^ पीछे रह सकता हूं। या तो . की सिम्बोलॉजी
मुझे समझ में आता है - यानी 'अप टू एंड इक्वल टू' या बस 'अप टू',
क्रमश। मेरे विचार से उन दोनों का एक ही अर्थ है।

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

किसी भी मामले में, मैं किसी न किसी रूप में एक शॉर्टहैंड नोटेशन पसंद करूंगा बनाम a
फ़ंक्शन कॉल जो स्पष्ट रूप से दाएं हाथ के वैल को +1 करता है। मैं पहले से सहमत हूं
टिप्पणी करता है कि यह किसी चीज़ को सौंपने के लिए एक वाक्यविन्यास बहुत आम है
एक समारोह कॉल की तरह लगता है। मैं भी बुरा नहीं मानूंगा ..., लेकिन दी, यह है
शायद = / == नए कपड़ों में बग और किसी को गोली मारने के लिए बाध्य
पैर...

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

ओह, क्या यह अभी भी बाइक शेडिंग के दौर में है? मैं

वापस पढ़ना, मुझे लगता है कि मैं @nikomatsakis से सहमत हूं कि इसे केवल ..= बनाएं और इसे एक दिन कॉल करें। .. बनाम ... की समानता बहुत सूक्ष्म है, और मैं इसके बजाय ... टोकन को वैरिएडिक जेनरिक (https://github.com/) के लिए अस्पष्टता के बिना उपयोग करना चाहता हूं। रस्ट-लैंग/आरएफसीएस/पुल/1935), जहां यह एक बहुत ही विशिष्ट उद्देश्य को पूरा करता है जिससे दोनों के बीच कम भ्रम पैदा होना चाहिए।

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

मुझे इसका उल्लेख करने से भी नफरत है क्योंकि यह सिर्फ अधिक शोर है, लेकिन इसके बारे में क्या .: (डॉट कोलन) समावेशी के लिए?

मुझे लगता है कि @ssokolow ने कुछ बेहतरीन अंक फिर से बनाए: UI/चतुर होना। मैं तर्क दूंगा कि आपकी आंखों को चकमा देने के लिए तीसरे बिंदु की दिशा को कुछ और देखने के लिए बदलना शायद उस श्रेणी में होगा।

मुझे व्यक्तिगत रूप से तीसरा बिंदु होने पर _zero_ आपत्ति है, यह जानने के अलावा कि यह अंततः कुछ लोगों की यात्रा करने के लिए बाध्य है। लेकिन यह समझाना भी आसान है, इसलिए मुझे यकीन नहीं है कि चतुर कामकाज को डिजाइन करने के लिए भाषा पर होना चाहिए। क्या '2 डॉट्स एक्सक्लूसिव हैं; 3 डॉट्स समावेशी' वास्तव में _that_ को समझना/डीबग करना मुश्किल है?

किसी भी मामले में - अंतिम निर्णय कौन लेता है, और इसे बंद करने के लिए अगला कदम क्या है? तीसरे चरित्र पर चर्चा करते हुए 18 महीने शायद इस बिंदु पर _is_ बाइक शेडिंग

सहमत, ^ यह एक कदम की तरह दिखता है।
आईएमओ अन्य op= ऑपरेटरों के साथ असंगतता कोई समस्या नहीं है क्योंकि ऐसा कोई तरीका नहीं है कि हमारे पास a ..= b के अर्थ में a = a .. b , क्योंकि .. है रेंज बनाने के लिए ऑपरेटर नहीं बल्कि सिंटैक्टिक शुगर (और हमारे पास एक सामान्य ऑप ओवरलोडिंग योजना नहीं है, जहां किसी भी ऑप को स्वचालित रूप से op= , और .. )।
मैं यह नहीं कह रहा हूं कि ..= डॉक्टर को देखे बिना स्पष्ट है। लेकिन एक बार लोगों ने डॉक्टर को देख लिया तो उसे याद रखना आसान हो जाता है, और उन्हें वैसे भी डॉक्टर को देखना होगा।

@nikomatsakis के नामांकन को देखते हुए, मुझे लगता है कि हम अगले सप्ताह की लैंग-टीम बैठक में इस पर चर्चा करेंगे, और उस समय एक कॉल करने की संभावना है। मैं मानता हूं कि इसके लिए केवल लैंग टीम को कॉल करने और बाइकशेडिंग को समाप्त करने की आवश्यकता है।

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

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

@solson इसके खिलाफ एक बहुत ही आकर्षक तर्क है।

ऐसा लगता है कि पर्ल में पूरी तरह से सामान्य वाक्यविन्यास है, .. अर्थ समावेशी (दोनों पर)
साइड) और ^ दोनों तरफ उस बाउंड को एक्सक्लूसिव बनाता है।

शनिवार, 18 मार्च, 2017 को शाम 6:51 बजे, जोश ट्रिपलेट नोटिफिकेशन @github.com
लिखा था:

@solson https://github.com/solson यह एक बहुत ही सम्मोहक तर्क है
इसके खिलाफ।

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

इसलिए, मुझे यह कहते हुए खेद है, लेकिन जब हमने @rust-lang/lang बैठक में इस मुद्दे पर चर्चा की, तो हम आम सहमति तक पहुंचने में विफल रहे। @withboats विशेष रूप से कुछ गंभीर आरक्षण हैं जो उम्मीद है कि वे अपने लिए प्रसारित कर सकते हैं।

कुछ प्रमुख बिंदु जिन पर हमने चर्चा की:

• यदि हमारे पास भाव और पैटर्न में एक समावेशी श्रेणी वाक्यविन्यास है, तो यह वही होना चाहिए
  
  
  
  • यानी, अगर हम x ..= y अपनाते हैं, तो इसका मतलब है कि मौजूदा x...y पैटर्न सिंटैक्स को हटाना।
  
  
• एक आकर्षक विकल्प है "कुछ न करें" और केवल (x..y).inclusive() या ऐसी ही कोई चीज़ लिखें। हालांकि, यह पैटर्न में काम नहीं करेगा (जो संभावित रूप से x...y रूप में रहेगा)। यह अपने आप में कुछ प्रश्न उठाता है:
  
  
  
  • क्या हम अभी भी अनन्य श्रेणी पैटर्न चाहते हैं? उदाहरण के लिए match 3 { 1..3 => false, .. }
    
    
    
    
    
    • यदि ऐसा है, तो हमारे पास वही संभावित भ्रम है!
    
    
    
  
  
  • @withboats ऐसा लगता है कि शायद हम इस तरह के पैटर्न नहीं चाहते हैं। मैं और @joshtriplett इस पर बिल्कुल आवश्यक महसूस करते हैं। =)
  
  
• एक्सक्लूसिव रेंज पैटर्न के आसपास एक और मुद्दा यह है कि (अस्थिर) स्लाइस पैटर्न के साथ खराब इंटरेक्शन (विवरण के लिए https://github.com/rust-lang/rust/issues/23121 देखें)।

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

• एक्सक्लूसिव रेंज एक्सप्रेशन के बारे में क्या करें?
• क्या हमें मौजूदा एक्सक्लूसिव रेंज पैटर्न को हटाना/बदलना है?
• समावेशी रेंज पैटर्न के बारे में क्या करना है?
• स्लाइस पैटर्न के बारे में क्या करें?

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

(और मुझे लगता है कि निको की पोस्ट के आखिरी हिस्से में, पहली बुलेट जो वर्तमान में "एक्सक्लूसिव रेंज एक्सप्रेशन" पढ़ती है, उसे "समावेशी रेंज एक्सप्रेशन" कहना चाहिए।)

टीएल; डीआर मेरी राय

रेंज एक्सप्रेशन के बारे में:

• हमें समावेशी श्रेणी के भावों के लिए कोई सिंटैक्स पेश नहीं करना चाहिए - न तो ... और न ही ..= ।
• हमें एक फ़ंक्शन को प्रील्यूड में जोड़ना चाहिए जो एक विशेष श्रेणी मान लेता है और एक समावेशी श्रेणी मान देता है। तो आप inclusive(0..10) लिखेंगे (नाम बाइकशेड किया जा सकता है)।

रेंज पैटर्न के बारे में:

• हमें विशेष रेंज पैटर्न, या किसी एक को बनाने का कोई तरीका नहीं पेश करना चाहिए।

दूसरे शब्दों में, केवल भौतिक परिवर्तन जो हमें करना चाहिए, वह है libs परिवर्तन: प्रस्तावना में एक फ़ंक्शन जोड़ें।

रेंज एक्सप्रेशन

मेरे तर्क के लिए मौलिक तथ्य यह है कि एक समावेशी श्रेणी मूल्य के माध्यम से पुनरावृत्ति एक असामान्य आवश्यकता है। मुझे लगता है कि यह इस तथ्य से पैदा हुआ है कि 18 महीने पहले आरएफसी स्वीकार किए जाने के बावजूद, हमने अभी भी इस सुविधा को स्थिर नहीं किया है - कार्यान्वयन के मुद्दों के कारण नहीं, बल्कि इसलिए कि हम ट्रेड ऑफ से खुश नहीं हैं।

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

विशेष रूप से, प्रत्येक वाक्यात्मक समाधान ने साझा किया है कि उनमें से कोई भी वास्तव में स्व-दस्तावेजीकरण नहीं है। यह अपेक्षाकृत स्पष्ट नहीं है कि 0...10 या 0..=10 एक समावेशी श्रेणी व्यंजक है। चूंकि उनका सामना अपेक्षाकृत कम ही होगा, इसलिए पहली बार उनका सामना करने वाले उपयोगकर्ताओं के लिए यह एक बड़ी बाधा होगी।

यही है, अगर उपयोगकर्ता यह भी नोटिस करता है कि वे "सामान्य" .. श्रेणी के साथ काम नहीं कर रहे हैं। बेशक, यह ... साथ बड़ी समस्या है, लेकिन ..= समस्या को पूरी तरह समाप्त नहीं करता है। यह आसान है, कोड के माध्यम से स्किमिंग करते समय, उस एक = वर्ण (या ^ या : या जो कुछ भी) को याद करना आसान है। अतिरिक्त . जितना आसान नहीं है, लेकिन मुझे यकीन नहीं है कि यह पर्याप्त रूप से ध्यान देने योग्य है।

मैं वास्तव में सोचता हूं कि ... और ..= बीच "ध्यान देने योग्य बनाम स्पष्टता" व्यापार बंद है। मुझे लगता है कि यह अधिक स्पष्ट है कि ... अर्थ क्या है (जब तक कि आप रूबी से नहीं आ रहे हैं, जहां दो वाक्यविन्यासों का विपरीत अर्थ है) ..= , लेकिन यह निश्चित रूप से कम ध्यान देने योग्य है ।

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

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

रेंज पैटर्न

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

दूसरा कारण यह है कि मुझे लगता है कि वे बहुत खराब शैली हैं (मुझे पता है कि अन्य लोग असहमत हैं)। उदाहरण के लिए:

if let 1..10 = x { .. }

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

इसमें "ऑफ-बाय-वन" मुद्दा भी है जो अभिव्यक्तियों में .. / ... है।

मुझे पता है कि निको ने उल्लेख किया है कि वह लिखना चाहता है:

match x {
    0..10 => { ... }
    10..20 => { ... }
}

लेकिन मैं वास्तव में दृढ़ता से देखना पसंद करूंगा:

match x {
    0...9 => { ... }
    10...19 => { .. }
}

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

मैं निश्चित रूप से समावेशी श्रेणी के भावों की तुलना में विशेष श्रेणी पैटर्न पर बोलबाला करना आसान महसूस करता हूं।

निरंतरता तर्क

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

वास्तव में, कोई कार्यान्वयन कनेक्ट भी नहीं है: 1..10 एक रेंज मान उत्पन्न करता है, जबकि 1...10 एक पूर्णांक मान से मेल खाता है। ऐसा नहीं है कि उनके पास एक संरचनात्मक/विनाशकारी कनेक्शन है जिस तरह से हमारे अधिकांश सममित अभिव्यक्ति/पैटर्न वाक्यविन्यास करते हैं।

यह "रेंज पैटर्न" की तुलना में पैटर्न को "डोमेन पैटर्न" कहने के लिए अधिक तकनीकी रूप से सही लगता है, जो गैर-समानता को हाइलाइट करता है।

@ नावों के बिना

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

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

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

विशेष रूप से, प्रत्येक वाक्यात्मक समाधान ने साझा किया है कि उनमें से कोई भी वास्तव में स्व-दस्तावेजीकरण नहीं है। यह अपेक्षाकृत स्पष्ट नहीं है कि 0...10 या 0..=10 एक समावेशी श्रेणी व्यंजक है। चूंकि उनका सामना अपेक्षाकृत कम ही होगा, इसलिए पहली बार उनका सामना करने वाले उपयोगकर्ताओं के लिए यह एक बड़ी बाधा होगी।

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

उदाहरण के लिए, मुझे कोई आपत्ति नहीं होगी, अगर एक समावेशी श्रेणी पैटर्न लिखने के लिए मैक्रो या समान की आवश्यकता होती है।

@joshtriplett यह वह जगह है जहां मैं वास्तव में स्पष्ट होना चाहता हूं, जब आप यह कहते हैं:

मैंने विभिन्न समयों पर आवश्यक दोनों अनन्य और समावेशी श्रेणियां पाई हैं (हालांकि मैंने स्थिर रस्ट पर काम करने के लिए दोनों मामलों के लिए अनन्य का उपयोग किया है, और ऊपरी बाउंड में +1 के साथ इसके आसपास काम करना था)।

ऐसा लगता है कि आप भावों के बारे में बात कर रहे हैं, लेकिन आपके द्वारा उद्धृत अनुभाग पैटर्न के बारे में था (मुझे पता है कि आप अपने अगले अनुच्छेद में पैटर्न के बारे में बात करते हैं, लेकिन मैं "आवश्यकता" मुद्दे के बारे में पूछ रहा हूं जो उस अनुच्छेद को संबोधित नहीं करता है ) .

पैटर्न के लिए यथास्थिति यह है कि हम केवल x...y फ़ॉर्म के समावेशी श्रेणी पैटर्न का समर्थन करते हैं। क्या आप इस बारे में अधिक बात कर सकते हैं कि क्या/जब आपको विशेष रेंज पैटर्न मिले हैं जो वास्तव में निराशाजनक हैं?

@ नावों के बिना

क्या आप इस बारे में अधिक बात कर सकते हैं कि क्या/जब आपको अनन्य श्रेणी पैटर्न मिले हैं जो वास्तव में निराशाजनक हैं?

कुछ इस तरह

    match offset {
        0x0200 .. 0x0280 => { /* GICD_ISPENDR<n> */ }
        0x0280 .. 0x0300 => { /* GICD_ICPENDR<n> */ }
        0x0300 .. 0x0380 => { /* GICD_ISACTIVER<n> */ }
        0x0380 .. 0x0400 => { /* GICD_ICACTIVER<n> */ }
        0x0400 .. 0x0800 => { /* GICD_IPRIORITYR<n> */ }
    }

बनाम

    match offset {
        0x0200 ... 0x027C => { /* GICD_ISPENDR<n> */ }
        0x0280 ... 0x02FC => { /* GICD_ICPENDR<n> */ }
        0x0300 ... 0x037C => { /* GICD_ISACTIVER<n> */ }
        0x0380 ... 0x03FC => { /* GICD_ICACTIVER<n> */ }
        0x0400 ... 0x07FC => { /* GICD_IPRIORITYR<n> */ }
    }

मैं यह नहीं कहूंगा कि यह विशेष रूप से निराशाजनक है, लेकिन पहला निश्चित रूप से अच्छा दिखता है।

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

@petrochenkov मुझे लगता है कि वे F में समाप्त होने वाले थे, न कि C ?

मैंने हेक्स रेंज पैटर्न के साथ एक ही मामले में भाग लिया है, उदाहरण के लिए 0x8000...0x9FFF => /* body */ । मुझे लगता है कि 0x8000..0xA000 में कुछ अधिक सहज गुण हैं, जैसे इसके बारे में सोचने के बिना मैं तुरंत देखता हूं कि सीमा का आकार 0xA000 - 0x8000 = 0x2000 और अगली आसन्न सीमा 0xA000 से शुरू होती है

इन तथ्यों को एक समावेशी श्रेणी में देखने के लिए आवश्यक +1 निपटना एक छोटा सा अंतर है जिसके साथ मैं रह सकता हूं, लेकिन विशिष्ट श्रेणियां (पैटर्न और अभिव्यक्ति दोनों) आमतौर पर मेरे काम के लिए बेहतर होती हैं।

@petrochenkov मैं देख सकता हूं कि आप हेक्सडिजिट्स के लिए विशेष श्रेणियां क्यों पसंद करेंगे (मैं अभी भी नहीं कर सकता, लेकिन यह एक बहुत ही वाईएमएमवी सौदे की तरह लगता है)।

हालांकि हम स्लाइस सिंटैक्स अस्पष्टताओं से कैसे निपटेंगे?

@joshtriplett

यदि समावेशी श्रेणी पैटर्न ... का उपयोग करते हैं और अनन्य श्रेणी अभिव्यक्ति .. उपयोग करते हैं तो मैं अभी भी बहुत भ्रमित हूं।

रस्ट आज इस तरह काम करता है और यह भ्रम का एक महत्वपूर्ण स्रोत नहीं लगता है?

@solson

मुझे लगता है कि वे एफ में समाप्त होने वाले थे, सी नहीं?

नहीं :)
(वे चीजें 32-बिट हैं और offset चार का गुणज है।)

@ नावों के बिना

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

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

हालांकि हम स्लाइस सिंटैक्स अस्पष्टताओं से कैसे निपटेंगे?

सरलता! PATTERN.. => .. @ PATTERN

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

1. एक समावेशी श्रेणी का उपयोग करना (सबसे साफ, लेकिन स्थिर नहीं)
2. + 1 से पहले अपकास्टिंग (मान लें कि मैं पहले से ही u64 पर नहीं हूं और सुरुचिपूर्ण है)
3. श्रेणी के लिए कम से कम मान और अधिकतम माइनस एक लेना, फिर उपयुक्त होने पर कार्य को एक बार और चलाना।

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

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

@ssokolow लेकिन उस उपयोग के मामले को प्रील्यूड फ़ंक्शन द्वारा आराम से कवर किया गया है। कोई भी यह स्थिति नहीं ले रहा है कि समावेशी श्रेणियां बनाना संभव नहीं होना चाहिए, बस उन्हें बनाने के लिए वाक्य रचनात्मक चीनी होनी चाहिए या नहीं।

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

जब आप जवाब दे रहे थे तो @withboats मैंने अपनी पोस्ट पर थोड़ा सा संपादित किया, लेकिन मैंने जो जोड़ा वह यह है कि समावेशी श्रेणियों को द्वितीय श्रेणी के नागरिक बनाना, वाक्य रचनात्मक रूप से (एक विशेष श्रेणी में + 1 जोड़ने से अधिक वाक्यविन्यास के साथ) ), उनका उपयोग करने के खिलाफ एक सूक्ष्म निराशा की तरह महसूस करता है और एक संभावित "मैं आपको cargo fuzz बाद में देखूंगा" फ़ुटगन।

अगर और कुछ नहीं, तो यह एक शिक्षण योग्यता मस्सा है।

रस्ट अपने असीमित पूर्णांक समर्थन के साथ Python 3.x नहीं है। जंग उपयोगकर्ताओं से हार्डवेयर ट्रेड-ऑफ को छिपाती नहीं है, और मुझे ..= बजाय u32 और दोस्तों के बजाय int । (विशेष रूप से यह देखते हुए कि ओवरफ्लो/अंडरफ्लो त्रुटियां cargo fuzz के "ट्रॉफी केस" पर अब तक की सबसे आम बात है।)

संपादित करें: कृपया इसके लिए केवल ई-मेल सूचनाओं में देखे गए किसी भी बिट को अनदेखा करें। मैं अभी उठा और मैं अभी तक सभी सिलेंडरों पर फायरिंग नहीं कर रहा हूं।

मैं inclusive(n..m) को निराशा के रूप में बिल्कुल नहीं देखता... मैं इसे लिखना पसंद करूंगा क्योंकि यह एक बहुत ही स्पष्ट निर्माण है जो मेरे कोड को n..(m + 1) और n..=m दोनों की तुलना में पढ़ने में आसान बनाता है

n..=m inclusive(n..m) IMO की तुलना में अधिक सिखाने योग्य मस्सा है।

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

संभवतः यदि "पिछले से जारी रखें" वाक्यविन्यास था, तो यह समस्या का समाधान भी करेगा।

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

    match offset {
        0 ... 0x01FF => {}
        0 ... 0x027C => { /* GICD_ISPENDR<n> */ }
        0 ... 0x02FC => { /* GICD_ICPENDR<n> */ }
        0 ... 0x037C => { /* GICD_ISACTIVER<n> */ }
        0 ... 0x03FC => { /* GICD_ICACTIVER<n> */ }
        0 ... 0x07FC => { /* GICD_IPRIORITYR<n> */ }
    }

मैं मानता हूं कि यह परिप्रेक्ष्य की बात हो सकती है, लेकिन:

1. जब मैं .. और ..= देखता हूं, तो मुझे लगता है "हुह। मुझे आश्चर्य है कि उनके पास इतने छोटे अंतर के लिए दो वाक्यविन्यास क्यों हैं", जो मुझे उन दस्तावेज़ों की तलाश करने के लिए प्रेरित करेगा जो ध्यान केंद्रित कर सकते हैं " 1..pivot और pivot..end " बनाम " x..=y जहां y अधिकतम संभव मूल्य हो सकता है"।

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

संपादित करें: ... और यह बिंदु 1 में वैचारिक भेद है जो मुझे लगता है कि हमें ध्यान केंद्रित करना चाहिए। (अर्थात "एक्स से पिवट तक" और "एक्स से अंत तक" प्रोग्रामर के दिमाग में अलग होना चाहिए।)

@pornel
यह भयानक है
इस विशिष्ट मामले में कोड पढ़ने वाले व्यक्ति के लिए सीमा प्रारंभ वास्तव में महत्वपूर्ण है, किसी भी समावेशी/अनन्य श्रेणी के मुद्दों से कहीं अधिक महत्वपूर्ण है।

@ssokolow यह मुझे ऐसा लगता है जैसे +1 एक मुद्दा पात्रों की संख्या नहीं है, लेकिन आपको अतिप्रवाह की संभावना को संभालना है। इसके अलावा यह इरादे को भी संप्रेषित नहीं करता है, और इसके लिए पूर्वता-माता-पिता के संघर्ष की आवश्यकता होती है। ये सभी वर्णों की संख्या से कहीं अधिक महत्वपूर्ण प्रतीत होते हैं।

यह सच है कि कोई व्यक्ति जो अतिप्रवाह के बारे में नहीं जानता है, वह एक समावेशी श्रेणी बनाने से पहले +1 तक पहुंच सकता है, लेकिन यह वाक्य रचना पर निर्भर नहीं लगता है। दोनों को पता चलता है कि ..= एक चीज है और यह कि inclusive() एक ऐसी चीज है जो सीखने के लिए सीखने योग्य क्षण पेश करती है कि आप विशेष रूप से समावेशी श्रेणियां क्यों चाहते हैं।

@पेट्रोचेनकोव

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

क्या आप विस्तार कर सकते हैं कि आप इसके बारे में इतनी दृढ़ता से क्यों महसूस करते हैं? मैं निश्चित रूप से केवल एक नकारात्मक पहलू के रूप में अनन्य पैटर्न को स्वीकार करना देखता हूं, इससे उपयोगकर्ताओं को एक अभिव्यक्ति के रूप में 0...10 उम्मीद हो सकती है, लेकिन यह मुझे उतना बुरा नहीं लगता।

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

("अगर मुझे कुछ उपयोगी लगे तो मैं पाठ्यपुस्तक नहीं पढ़ना चाहता... मैं बस एक सीमा पर पुनरावृति करना चाहता हूं और प्रगति पर वापस जाना चाहता हूं।")

@withboats यदि हमारे पास समावेशी (ए..बी) है, लेकिन हम इसे मैच में उपयोग नहीं कर सकते हैं, तो यह आईएमओ के लायक नहीं है।
अधिकांश समय जब मैं समावेशी श्रेणियों का उपयोग कर रहा होता हूं, तो यह मिलान पैटर्न में होता है!
तो क्यों न हम ... हटा दें और मैच के अंदर और बाहर सिर्फ ..= उपयोग करें?

@ बॉस्कोप का प्रस्ताव मैच में ... को हटाने का नहीं है, बल्कि पैटर्न को ठीक उसी तरह छोड़ने का है जैसे वे स्थिर हैं।

@ssokolow ऐसा लगता है कि .. अनुभाग में एक नोट के साथ बहुत आसानी से हल किया जा सकता है

@withboats लेकिन मैच में ... को क्यों न हटाएं और इसके बजाय ..= उपयोग करें, इसलिए यह सुसंगत है?
(ताकि यह मैच के अंदर और बाहर ..= हो)

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

match x {
    0.0...3.141592653589792 => 1,
    3.141592653589793...6.283185307179585 => 2,
    6.283185307179586...10.0 => 3,
    _ => 4,
}

और इसे ओवरलैप के साथ लिखना इसके बजाय icky लगता है (और नैतिक रूप से "बस से सब कुछ शुरू करें -∞ के बाद से हथियारों का आदेश दिया जाता है" के समान)। डेटाटाइम भी देखें, जैसे कि कैसे ISO8601 T24:00 की अनुमति देता है, क्योंकि एक दिन [00:00, 24:00) है, न कि [00:00, 23:59:59]। या तार, या परिमेय, या ...

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

(इसके अलावा: इंडेक्सिंग के लिए 1 <= x <= N पैटर्न वास्तव में 0 < x <= N रूप में बेहतर किया जाता है, जो कि अनन्य भी है - हालांकि आधे खुले के बजाय आधा बंद - उन्हीं कारणों से दिज्क्स्ट्रा ने कहा, बस 0-आधारित के बजाय 1-आधारित अनुक्रमण के लिए स्विच किया गया।)

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

0.0..1.0+ईपीएसआईएलओएन

मुझे यकीन नहीं है कि यह सही है, लेकिन अभी फ़्लोटिंग पॉइंट नंबरों की एक समावेशी श्रेणी घोषित करना बहुत मुश्किल है।

ऐसा करने का सही तरीका होगा nextafter , न कि एप्सिलॉन। यानी x...y == x..nextafter(y) । ieee754 क्रेट ऐसी कार्यक्षमता को उजागर

ओह, मैंने inclusive(a..b) सिंटैक्स के बारे में एक टिप्पणी की लेकिन मुझे एहसास हुआ कि यह सच नहीं था। वैसे भी, मुझे यह पसंद है लेकिन मुझे उम्मीद है कि हम एक बेहतर नाम की बाइक चला सकते हैं।

@durka नाम मुझे स्पष्ट लगता है। क्या आप इसके साथ अपनी चिंताओं के बारे में विस्तार से बता सकते हैं?

तो समावेशी श्रेणियों के लिए हमारे पास a ... b में match और inclusive(a..b) मैच के बाहर होंगे?
हम सुसंगत क्यों नहीं हो सकते हैं और हर जगह a ..= b ?

क्या ops::{RangeInclusive, RangeToInclusive} को औपचारिक रूप से स्थिर होने से कोई रोक रहा है?

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

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

एक बात मैंने दूसरे दिन RangeInclusive के बारे में देखी: यदि आप किसी श्रेणी को स्वीकार करने का प्रयास कर रहे हैं तो इसके विरुद्ध कोड करना एक दर्द है। क्लैंप थ्रेड अनुमति देने के बारे में बात कर रहा था .clamp(1...9) , लेकिन कोड कुछ इस तरह दिख रहा है:

    fn clamp(self, r: RangeInclusive<Self>) -> Self where Self : Sized {
        match r {
            RangeInclusive::Empty { .. } =>
                panic!("Cannot clamp to an empty range"),
            RangeInclusive::NonEmpty { start, end } => {
                assert!(start <= end, "Cannot clamp to a degenerate range");
                if self < start { start }
                else if self > end { end }
                else { self }
            }
        }
    }

RangeInclusive::Empty से निपटने की आवश्यकता अनावश्यक महसूस होती है क्योंकि लक्ष्य सिर्फ जोड़ी को अच्छे वाक्यविन्यास के साथ स्वीकार करना है। यदि यह एक एनम नहीं होता, तो यह सिर्फ fn clamp(self, RangeInclusive { start, end }: RangeInclusive<Self>) , और बहुत साफ हो सकता है।

दुर्भाग्य से मेरे पास इसके बारे में क्या करना है, इसके बारे में कोई अच्छा जवाब नहीं है, हालांकि, समावेशी पर .into_iter() की आवश्यकता है लेकिन अनन्य नहीं भी दुर्भाग्यपूर्ण होगा ...

यादृच्छिक विचार: यह देखते हुए कि कैसे ... पैटर्न सिंटैक्स वास्तव में समावेशी श्रेणी प्रकारों से संबंधित नहीं है, हम यहां प्रस्तावित ... से असंबंधित एक के पक्ष में इसके सिंटैक्स को पदावनत करने पर विचार कर सकते हैं।

चूंकि एक समावेशी श्रेणी पैटर्न | पैटर्न से अधिक निकटता से संबंधित है, |... एक अच्छा उम्मीदवार हो सकता है:

match {
    1 | 2 | 3 => ...
    1 |... 3  => ...
}

अंतिम परिणाम यह होगा कि समावेशी और अनन्य श्रेणी सिंटैक्स का अब मिलान करने वाले पैटर्न से कोई 1:1 संबंध नहीं है, और इस प्रकार इसके अनुरूप होने की आवश्यकता नहीं है।

@scottmcm

दुर्भाग्य से मेरे पास इसके बारे में क्या करना है, इसके बारे में कोई अच्छा जवाब नहीं है, हालांकि, समावेशी पर .into_iter() की आवश्यकता है लेकिन अनन्य नहीं भी दुर्भाग्यपूर्ण होगा ...

हो सकता है कि हम range.nonempty() जैसे सहायक को जोड़ सकते हैं जो एक खाली सीमा के लिए घबराता है, और एक जोड़ी लौटाता है?

वैकल्पिक रूप से हम IntoIterator को RangeInclusive लिए लागू कर सकते हैं और यह IMHO से बहुत दूर नहीं होगा।

रेंज इन्क्लूसिव :: खाली सर्व किस उपयोग के मामले में करता है? एक समावेशी श्रेणी को रिक्त श्रेणी का प्रतिनिधित्व करने की क्षमता की आवश्यकता क्यों है? आप एक कैसे लिखेंगे? (ध्यान दें कि आप पहले से ही "5 से 4 तक की सीमा, समावेशी" जैसी चीजें लिख सकते हैं, जो पुनरावृत्ति संभावित रूप से खाली मानी जाएगी।)

@joshtriplett मुख्य मामला अतिप्रवाह है, हालांकि उस समस्या को हल करने के तरीके हैं।

@joshtriplett start > end वास्तव में एक महत्वपूर्ण मामले में खाली समावेशी श्रेणी का प्रतिनिधित्व करने के लिए काम नहीं करता है: 0u8...255u8 । जब आप 255u8...255u8 और इसे .next() करते हैं, तो आप या तो घबरा जाएंगे या 0u8...255u8 लपेट जाएंगे, जो खाली नहीं है। इसलिए इसके बजाय हम उस बिंदु पर Empty संस्करण पर स्विच करते हैं।

@solson आह, मैं देखता हूँ। हाँ, यह एक दर्द है, और यह समावेशी श्रेणियों के लिए सबसे बड़े उपयोग के मामलों में से एक है।

(मुझे लगता है कि उन सभी मामलों में आपका मतलब 255u8 है।)

(मुझे लगता है कि उन सभी मामलों में आपका मतलब 255u8 है।)

हाँ धन्यवाद। संपादित।

@solson हालांकि, उस मामले में 0 और 255 को स्वैप करके इस मामले को ठीक किया जा सकता है

@clarcharr यह सच है। चूंकि .next() हमेशा Empty श्रेणी की पीढ़ी को विशेष-मामला करना पड़ता है, यह हमेशा एक सीमा उत्पन्न कर सकता है जिसे खाली माना जाएगा।

व्यक्तिगत रूप से मुझे वह तरीका बेहतर लगता है क्योंकि इसमें खाली सीमा शामिल नहीं है।

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

रस्ट स्टेबल आज क्या करता है:

0..5 एक अर्ध-खुली सीमा का प्रतिनिधित्व करता है, [0, 1, 2, 3, 4] जिसका उपयोग पैटर्न मिलान में नहीं किया जा सकता है
0...5 एक बंद श्रेणी का प्रतिनिधित्व करता है [0, 1, 2, 3, 4, 5] जिसका उपयोग केवल पैटर्न मिलान में किया जा सकता है।

एक अतिरिक्त क्लोज्ड रेंज सिंटैक्स के लिए कई रूपों का प्रस्ताव किया गया है जिसका उपयोग पैटर्न मिलान के बाहर किया जा सकता है। मैं हर एक और उनके लाभ और कमियों को कवर करूंगा।

0...5

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

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

0..=5

पेशेवरों: गलत टाइप करने के लिए और अधिक कठिन, अधिक अर्थपूर्ण रूप से स्पष्ट

विपक्ष: मौजूदा पैटर्न मिलान सिंटैक्स के साथ असंगत। उपयोगकर्ताओं को यह पूछने का कारण हो सकता है: ऐसा क्यों है ... यहाँ लेकिन ..= यहाँ?

0..^5

..= समान ही लेकिन इसमें एक अतिरिक्त कॉन है जिसमें यह एक घातांक ऑपरेटर की तरह दिखता है।

inclusive(0..5)

पेशेवरों: अत्यधिक अर्थपूर्ण रूप से स्पष्ट। गलत टाइप नहीं किया जाएगा।

विपक्ष: लंबे समय की तरह। पैटर्न मिलान सिंटैक्स के साथ भी असंगत।

0....5

पेशेवरों: ... की गलत टाइपिंग की समस्या से भी बचा जाता है

विपक्ष: खराब शब्दार्थ, पैटर्न मिलान सिंटैक्स के साथ असंगत और पैटर्न मिलान सिंटैक्स के समान।

[0..5] अनुपयोगी। कोष्ठक का पहले से ही भाषा में वाक्यात्मक महत्व है।

0..<=5 अनुपयोगी। किसी मान की किसी श्रेणी से तुलना करने के लिए मौजूदा सिंटैक्स के साथ विरोध.

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

एक अधिक सामान्य प्रयोजन श्रेणी सिंटैक्स बनाने के बारे में भी कुछ चर्चा हुई है जो आपको ऊपरी और निचली दोनों सीमाओं को समावेशी या अनन्य बनाने की अनुमति देगा, लेकिन हमें शायद उस सिंटैक्स की भी आवश्यकता नहीं है क्योंकि आधा-खुला और बंद सीमा संभावित कवर खत्म हो गया है 99.9999% उपयोग के मामले।

मैंने इस चर्चा को यथासंभव बेहतर ढंग से प्रस्तुत करने का प्रयास किया। अगर आपको लगता है कि मैंने आपकी बात को पर्याप्त रूप से व्यक्त नहीं किया है तो कृपया मुझे बताएं ताकि मैं इसे अपडेट कर सकूं।

@Xaeroxe उत्कृष्ट सारांश के लिए धन्यवाद।

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

मुझे लगता है कि एक चीज जो हम सिंटैक्स मुद्दे पर पंट करने के लिए कर सकते हैं, वह है रेंजइन्क्लूसिव को स्थिर करना, जैसा कि

हम inclusive फ़ंक्शन भी जोड़ सकते हैं (या तो केवल std::range या संभवतः प्रस्तावना में भी); यह किसी दिन प्रथम श्रेणी के सिंटैक्स होने से रोकता नहीं है लेकिन यह अभी एक रेंज समावेशी बनाने के लिए इसे और अधिक सुविधाजनक बनाता है।

हालांकि, ये सभी libs निर्णयों की तरह प्रतीत होते हैं, इसलिए मुझे नहीं पता कि लैंग टीम के पास इन वस्तुओं को स्थिर/जोड़ने का निर्णय लेने का अधिकार क्षेत्र है या नहीं।

मैं व्यक्तिगत रूप से RangeInclusive को किसी ऐसी चीज़ में बदलना पसंद करूंगा जिसका Empty संस्करण नहीं है, फिर एक IntoIter को संस्करण बनाएं। यह मेरे लिए और अधिक समझ में आता है कि मैन्युअल रूप से Empty { at } बिना खाली सीमा बनाना अनिवार्य रूप से असंभव कैसे है।

वैकल्पिक रूप से, एक किनारे के मामले पर MAX और MIN स्वैप करें जिसका मैंने उल्लेख किया था। इससे RangeInclusive जुड़े अधिक सामान्य कोड लिखना कठिन हो जाता है, लेकिन यह समस्या का उचित समाधान प्रतीत होता है।

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

@scottmcm मैं मानता हूं कि इस बिंदु पर शायद एक अलग धागा होना चाहिए।

वाक्य रचना चर्चा को आगे बढ़ाने के प्रयास में मैं वह मार्ग प्रस्तुत करने जा रहा हूं जिसे मैं लेना पसंद करूंगा।

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

मेरा प्रस्ताव प्रदान किए 24 दिन हो चुके हैं और कोई टिप्पणी नहीं दी गई है। क्या हमें उस योजना के साथ आगे बढ़ना चाहिए?

संपादित करें: मोबाइल पर मुझे थम्स डाउन्स दिखाई नहीं दे रहे थे, इसलिए मुझे नहीं पता था कि असहमतिपूर्ण राय थी।

@Xaeroxe मुझे ऐसा नहीं लगता। मैं इस बात से सहमत नहीं हूं कि ... को ..= पक्ष में पदावनत करना उन कारणों के लिए एक अच्छा विकल्प है जिन्हें मैंने पहले ही इस थ्रेड में पोस्ट कर दिया है। मैंने आपके विशिष्ट प्रस्ताव का उत्तर नहीं दिया क्योंकि वही विचार पहले ही सामने रखा जा चुका था और उस पर चर्चा की जा चुकी थी। यहां केवल एक चीज स्पष्ट है कि हमारे बीच आम सहमति नहीं है। मुझे लगता है कि हममें से कई लोग चर्चा से थकान महसूस करते हैं।

संपादित करें: अधिक विशिष्ट होने के लिए, मैं ... के पक्ष में ..= को पदावनत नहीं करना चाहता क्योंकि:

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

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

मैं वास्तव में ऐसी चीजों के साथ अनुभव की कमी के कारण बहिष्करण की लागत पर टिप्पणी नहीं कर सकता। हालांकि मैं अभी भी ..= समर्थन में हूं।

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

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

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

मैं इस समय पैटर्न मिलान के बाहर के उदाहरणों के लिए inclusive फ़ंक्शन और पैटर्न मिलान में ... का उपयोग करने के समर्थन में हूं।

@ नावों के बिना

1. यदि आप कभी भी किसी भी चीज़ की अवहेलना नहीं करते हैं, तो आप C ++ जैसे सभी (अधिक या कम) बुरे निर्णयों के मिलन के साथ समाप्त हो जाते हैं। यह नए लोगों को और भी अधिक सीखने के लिए मजबूर करता है क्योंकि चीजें उतनी सुसंगत नहीं हैं जितनी हो सकती हैं।
   तो कभी-कभी बेहतर समाधान के लिए रास्ता बनाने के लिए सामान को बहिष्कृत करना समझ में आता है।

2. इसका मतलब यह नहीं है कि उपयोगकर्ता, इसे पहली बार देखकर, जान जाएगा कि वे क्या देख रहे हैं।

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

1. 
   यदि आप उस समय को कम करने की परवाह करते हैं जब नए लोगों को डॉक्टर को देखना पड़ता है, तो हमें समावेशी श्रेणियों के निर्माण और मिलान के बीच समरूपता के लिए प्रयास करना चाहिए! (और अन्य निर्माण)

जैसा कि @withboats ने कहा, मुझे लगता है कि हम में से बहुत से लोग इस चर्चा से थक चुके हैं; मैं एक के लिए इसे थोड़ी देर के लिए बैठा रहा हूं। उस ने कहा, मुझे फिर से पढ़ने में कुछ समय लगा (सारांश @Xaeroxe के लिए धन्यवाद!)

IMO, अभी सबसे महत्वपूर्ण समस्या हमारे द्वारा प्रदान किए गए सिंटैक्स का अधूरा संयोजन है : ... पैटर्न में, .. अभिव्यक्तियों के लिए। वाक्य रचना की यह जोड़ी आपको दृढ़ता से यह उम्मीद करने के लिए प्रेरित करती है कि .. पैटर्न में काम करेगा और ... अभिव्यक्तियों में - और वे नहीं करते हैं। मेरा मानना ​​​​है कि यह लंबी अवधि में एक टिकाऊ डिजाइन नहीं है, और वास्तव में इसे ठीक करना चाहता हूं।

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

• अभिव्यक्तियों में ... को स्थिर करें और पैटर्न में .. जोड़ें। यह कम से कम दर्दनाक परिवर्तन है, लेकिन इसमें ऑफ-बाय-वन त्रुटियों के बारे में अच्छी तरह से चर्चा की गई है। फिर भी, अन्य भाषाओं में यह संयोजन है और मेरी जानकारी में, ऐसी त्रुटियों के साथ बहुत अधिक नुकसान नहीं हुआ है।

• विरोध ... पैटर्न और भाव में, जोड़ने ..= दोनों के लिए, और जोड़ने .. पैटर्न के लिए। ऊपर की कमियों को हल करता है, अधिक दर्दनाक है (बहिष्करण के कारण), और भविष्य में अन्य प्रकार की श्रेणियों (जैसे बाएं-अनन्य) के लिए द्वार खोलता है।

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

फिर भी, अन्य भाषाओं में यह संयोजन है और मेरी जानकारी में, ऐसी त्रुटियों के साथ बहुत अधिक नुकसान नहीं हुआ है।

मुझे यहां चयन पूर्वाग्रह की चिंता है। हमारे पास यह तय करने का कोई विश्वसनीय तरीका नहीं है कि क्या समस्याएं मामूली हैं या क्या वे शायद ही कभी हमारे ध्यान में आती हैं।

इसके अलावा, ... ऐसा लगता है कि यह रस्ट के डिजाइन दर्शन और उभरती सर्वोत्तम प्रथाओं के "जब तक ट्रेड-ऑफ बहुत गंभीर नहीं है" पहलू के विपरीत चलता है। (जैसे। सलाह नया बनाने के लिए enum बल्कि उपयोग करने की तुलना प्रकार bool तो यह कठिन अपने समारोह पैरामीटर मिश्रण है।)

उदाहरण के लिए, सी ने साबित कर दिया है कि if स्टेटमेंट में असाइनमेंट उपयोगी है यदि किसी भाषा में while let , लेकिन यह माना गया है कि टाइप करना = जब आपका मतलब == एक फुटगन के लिए पर्याप्त है कि पायथन जैसी भाषाएं इसे मना कर देती हैं, तब भी जब ऐसी परिस्थितियां मौजूद हों जहां एकमात्र विकल्प अस्वाभाविक रूप से बदसूरत हों।

दूसरी दिशा में जा रहे हैं, मैंने वास्तव में क्लिप्पी को इस तरह का मामला पकड़ लिया था जब मैं लगभग एक हफ्ते पहले थके हुए कोडिंग कर रहा था ...

foo == bar;  // This should be `foo = bar;`

... जो "कुंजी को कई बार दबाया" गलती का एक आदर्श उदाहरण की तरह लगता है कि हम यहां चिंतित हैं ... और, " == विपरीत कोई प्रभाव नहीं है", वहां है .. बनाम ... लिए लिंट करने का कोई अच्छा तरीका नहीं है।

@ssokolow स्पष्ट होने के लिए, मैं ..= भी ठीक हूं; मुझे नहीं लगता कि बहिष्करण इतना दर्दनाक होगा, और यह एक बहुत ही आसान स्वचालित सुधार है। ज्यादातर मैं सिर्फ इस मुद्दे को सुलझाना चाहता हूं।

मैं शायद .. / ... (जो पहले से ही रात को लागू किया गया है) को स्थिर करने के साथ रह सकता हूं। मैं @aturon से सहमत

जैसा कि मैंने कहा है, मैं वास्तव में libstd प्रकार को स्थिर करना चाहता हूं जब rust-lang/rfcs#1980 सिंटैक्स चर्चा की आवश्यकता के बिना गुजरता है।

@aturon ने जो बताया,

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

18 मई, 2017 को 9:55:30 पूर्वाह्न पीडीटी पर, हारून ट्यूरॉन नोटिफिकेशन @github.com ने लिखा:

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

मैं एक सम्मेलन के कारण अगले सप्ताह की बैठक के लिए बाहर जा रहा हूँ। यदि अगले सप्ताह की बैठक में इस पर चर्चा होती है, तो मैं ... अलावा किसी भी समाधान के लिए अपना समर्थन दूंगा, चाहे ..= , inclusive , या अन्य।

जब हम इस पर हों तो रेस्ट/स्प्रेड सिंटैक्स पर चर्चा करना उचित होगा।
मैं वोट .. विशेष श्रृंखला के लिए, ... समावेशी के लिए, .... बाकी / प्रसार के लिए।

take_range(..max); // exclusive range
take_range(...max); // inclusive range
take_multiple_args(....tuple); // spread
if let 0..10 = get_num() {} // exclusive range pattern
if let 0...9 = get_num() {} // inclusive range pattern
if let [first, ....rest] = get_slice() {} // rest pattern

मैं दो कारणों से बाकी स्लाइस के लिए ... वोट दूंगा:

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

2. जब तक मैं रेंज के लिए .. और ..= का उपयोग करके रस्ट के सिंटैक्स के बारे में कुछ याद नहीं कर रहा हूं, लेकिन बाकी स्लाइस के लिए ... मतलब यह होगा कि, हर स्थिति में, ... टाइप करना .. या इसके विपरीत अभी भी एक संकलन-समय त्रुटि होगी।

   इसके लिए मैं दो धारणाओं पर काम कर रहा हूं:

   1. अकेले बाकी सिंटैक्स का उपयोग करना (एक अनुक्रम-अनपॅकिंग संदर्भ के बाहर) को टाइपो-प्रवण नो-ऑप के रूप में अस्वीकार कर दिया जाएगा। (यानी for _ in ...rest की अनुमति होने पर for _ in rest होगा, लेकिन लगभग निश्चित रूप से एक टाइपो।

   2. असाइन किए जाने वाले पैटर्न के रूप में ओपन-एंडेड रेंज का उपयोग करना अमान्य होगा। (यानी let [first, ..rest] = अमान्य होगा।)

@ssokolow ट्रिपल डॉट का मतलब पहले से ही पैटर्न में एक सीमा है ताकि इसे बाकी सिंटैक्स में बदलने के लिए एक ब्रेकिंग बदलाव हो।

@ फाक्स प्वाइंट। मैं इसके बारे में किसी कारण से भूल गया था।

शायद "अगर हम कभी जंग 2.0 बनाते हैं" टैग को बंद करने के लिए कुछ।

ट्रिपल डॉट का मतलब पहले से ही पैटर्न में एक सीमा है, जो इसे बाकी सिंटैक्स में बदलने के लिए एक ब्रेकिंग बदलाव होगा।

हालांकि, पैटर्न में ... दोनों पक्षों पर एक अभिव्यक्ति होनी चाहिए, मेरा मानना ​​​​है कि ( a...b ), जबकि बाकी वाक्यविन्यास ... उपसर्ग के रूप में उपयोग करता है, नहीं?

लैंग टीम ने आज हमारी बैठक में इस सुविधा पर फिर से चर्चा की, और मोटे तौर पर निम्नलिखित मैट्रिक्स पर पहुंचे:

• सहायक ... पैटर्न में और .. भाव में, और कुछ नहीं, एक अस्थिर डिजाइन है, यह उपयोगकर्ताओं को सिंटैक्स को काम करने की अपेक्षा करता है जो नहीं करेगा।

• दोनों जगहों पर ... और .. अनुमति देने से मदद मिलेगी, लेकिन अलग-अलग समस्या एक वास्तविक चिंता है; हम में से कोई भी लोगों द्वारा गलत अवधि को ट्रैक करने में घंटों खर्च करने की रिपोर्ट प्राप्त करने के लिए उत्सुक नहीं है।

• ..= और .. जाना सौंदर्य की दृष्टि से कम आकर्षक है, लेकिन उपरोक्त वास्तविक व्यावहारिक समस्याओं से बचा जाता है। हम इसे बहुत ही सौम्य तरीके से भी रोल आउट कर सकते हैं: पहले ..= को एक वैकल्पिक सिंटैक्स के रूप में पेश करें (जिसे rustfmt फिर से लिख सकता है), और इसके मुहावरेदार बनने के बाद ही, ... हटा दें।

यदि आप नहीं बता सकते हैं, तो टीम को लगता है कि ..= और .. आगे बढ़ने का हमारा सबसे अच्छा रास्ता है। इस मुद्दे पर भी इस बिंदु पर चर्चा की गई है कि इसकी बहुत संभावना नहीं है कि नए तर्क उठाए जाएंगे, इसलिए हम इसका लाभ उठाने के लिए तैयार हैं: हम किसी ऐसे व्यक्ति की तलाश कर रहे हैं जो दोनों के लिए ..= अंकन को लागू करना चाहेगा। पैटर्न और भाव, और बाद में हम जाएँगे FCP!

इसके लिए, हम कार्यान्वयन को आगे बढ़ाने के लिए किसी (या कुछ लोगों) की तलाश कर रहे हैं। संभवतः यह कई छोटे पीआर में किया जा सकता है:

• प्रारंभ करने के लिए, के शामिल कर सकते हैं ..= के लिए एक उपनाम के रूप पार्सर के लिए ... और मौजूदा परीक्षण कन्वर्ट।
  
  
  
  • ... निश्चित रूप से काम करते रहना चाहिए, और हम चाहते हैं कि यह एक "मौन" बहिष्करण हो, इसलिए चेतावनी आदि (अभी तक) जारी करने की कोई आवश्यकता नहीं है।
  
  
  • इसलिए हमें परीक्षणों को ... पैटर्न पर रखने की आवश्यकता होगी
  
  
  • मुझे लगता है कि शायद ऐसा करने का तरीका DotDotEquals टोकन जोड़कर लेक्सर को संशोधित यहां मौजूदा DotDotDot ) और फिर हर जगह DotDotEquals स्वीकार करने के लिए पार्सर को संशोधित DotDotDot स्वीकार करें ( उदाहरण )
  
  
  • ripgrep DotDotDot यहां आपका मित्र है;)
  
  
• अभिव्यक्तियों में ... कभी भी स्थिर नहीं था, इसलिए हम इसे केवल ..= बदल सकते हैं और पुराने समर्थन को समाप्त कर सकते हैं
  
  
  
  • जंगली लोगों के लिए अच्छा होने के लिए, हम एक बहिष्करण अवधि के माध्यम से जा सकते हैं, लेकिन मुझे यकीन नहीं है कि यह आवश्यक है (विचार?)
  
  

बस ध्यान दें कि, लागू करते समय, सिंटैक्स extern fn foo(a: u32, ...) को ..= नहीं बदला जाना चाहिए।

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

मैं व्यक्तिगत रूप से ..^ तुलना में ..= पक्ष में अधिक हूं, क्योंकि a operator= b पहले से ही, कुछ ऑपरेटरों के लिए, a = a operator b लिए एक उपनाम है। दूसरी ओर ^ का उपयोग बहुत कम किया जाता है, केवल XOR के लिए, इसलिए इसे कम भ्रम पैदा करना चाहिए।

.. लिए बाएं और दाएं ऑपरेंड के प्रकार की तुलना में एक अलग प्रकार उत्पन्न करता है, इसलिए मुझे नहीं लगता कि यह ..= लिए कोई समस्या है। संदर्भ भी ऑपरेटर के उद्देश्य की पहचान करने में मदद करता है, जैसे += () इसलिए यह अपने स्वयं के कथन के रूप में प्रकट हो सकता है, आमतौर पर अपनी लाइन पर। जबकि ..= समावेशी रेंज लौटाता है, इसलिए यह अन्य निर्देशों के अंदर एक अभिव्यक्ति के रूप में दिखाई देगा। इसके अलावा जैसा कि ऊपर उल्लेख किया गया है ..^ ऐसा लगता है कि यह एक सीमा की तुलना में घातांक के साथ अधिक करना है।

@Xaeroxe ^ का घातांक के साथ रस्ट में कोई लेना-देना नहीं है (हालाँकि इसका उपयोग अन्य भाषाओं में किया जाता है), जबकि += , -= , *= सभी जंग में मौजूद है। वास्तव में ^= मौजूद है।

लेकिन idk, इसका ठीक ..= भी है।

चूंकि #42134 का विलय कर दिया गया था, क्या अब हम पुस्तकालय संरचना को स्थिर करने के लिए आगे बढ़ सकते हैं? मुझे लगता है कि हम सिंटैक्स को स्थिर करने से पहले व्यवस्थित होने की प्रतीक्षा करना चाहते हैं, हालांकि जैसा कि मैंने पहले कहा था, यह जल्द ही संरचना को स्थिर करने में मददगार होगा।

@clarcharr मेरा मानना ​​​​है कि हम उस संरचना के साथ-साथ ..= सिंटैक्स को स्थिर करने के निर्णय पर आए हैं, इसलिए हमें वास्तव में ऐसा करने के लिए कुछ पीआर की आवश्यकता है।

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

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

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

यह वाक्यविन्यास बेकार है!
= असाइनमेंट का अर्थ है, यहां तक ​​कि +=, -=, *= मॉडल में भी, लेकिन ..= कुछ पाने के बारे में है। इतना भ्रमित और बदसूरत।
जैसे एरे इंडेक्स 0 से शुरू होता है, '...' अच्छा और सुंदर है, लोगों को इसकी आदत हो जाएगी।

@zengsai
..= अवधारणात्मक रूप से == और <= जैसे ऑपरेटरों से लिया गया है, जो पहले से ही जंग में मौजूद हैं और समानता तुलना इंगित करते हैं, असाइनमेंट नहीं।

(यानी 1..=5 "रेंज ओवर वैल्यूज 1 <= x <= 5 " के लिए शॉर्टहैंड है, जैसा कि 1..5 विपरीत है जिसका अर्थ है "रेंज ओवर वैल्यूज 1 <= x < 5 ")

संपादित करें: इसके अलावा, यह "इसकी आदत डालने" की बात नहीं है, यह एक ऐसा मामला है जिसे गलत तरीके से पढ़ना या गलत टाइप करना अधिक कठिन होता है जब आप थके हुए या विचलित होते हैं। इस तरह की ऑफ-बाय-वन त्रुटियां प्रसिद्ध फुटगन-वाई हैं।

मैंने वास्तव में गलती से ... टाइप कर दिया था जब मेरा मतलब पहले से ही .. । शुक्र है, मैं हमेशा स्थिर जंग को लक्षित करता हूं, इसलिए संकलक ने इसे पकड़ लिया। (हालांकि, मुझे यह याद नहीं है कि यह मांसपेशियों में ऐंठन थी या मांसपेशियों की स्मृति, यह मानते हुए कि मैं एक छद्म-दीर्घवृत्त टाइप करना चाहता था क्योंकि मैं बहुत सारे गैर-कथा लेखन करता हूं।)

@zengsai ... बहुत सूक्ष्म है, .. समान दिखता है

किसी भाषा के लिए अलग-अलग बिंदुओं का अर्थ अलग-अलग चीजों का होना वास्तव में असामान्य होगा

सौंदर्य की दृष्टि से आकर्षक होने की तुलना में फुट गन को हटाना अधिक महत्वपूर्ण है।

नवागंतुक: मैंने एक टीएल; डीआर बनाया है, क्योंकि यह बहुत लंबा धागा है। आप इसे यहां पढ़ सकते हैं: https://github.com/rust-lang/rust/issues/28237#issuecomment -296310123

"ऑफ-बाय-वन त्रुटियां जैसे कि प्रसिद्ध फुटगन-वाई" के लिए बोलते हुए, मेरा कहना है: टाइपो समस्या को इस परिवर्तन के प्रमुख कारण के रूप में उपयोग नहीं किया जाना चाहिए।

इस तुलना को देखें, ".." और "..." बनाम "=" और "==", क्या इसका मतलब है कि हमें उपयोगकर्ता के टाइपो मुद्दे से बचने के लिए "==" के लिए अन्य वाक्यविन्यास मिलना चाहिए? अगर "=" और "==" ठीक है, तो ".." और "..." क्यों नहीं कर सकते हैं?

मैं दो साल से अधिक समय से रस्ट-लैंग का पालन कर रहा हूं। चींटी यह मेरे कई निजी प्रोजेक्ट में इस्तेमाल किया गया है। मुझे यह पसंद है, लेकिन यह वाक्य रचना वास्तव में मुझे असहज महसूस कराती है। न केवल सौंदर्य की दृष्टि से आकर्षक, यह कोड के लेखन और पढ़ने के प्रवाह को भी प्रभावित करता है।

@zengsai यह मेरी समझ थी कि यह मुख्य रूप से _writing_ कोड के बारे में नहीं है, बल्कि कोड की समीक्षा, पढ़ने और समझने के बारे में है। यदि आप इसकी तलाश नहीं कर रहे हैं, तो आप .. बनाम ... को एक-एक-एक त्रुटि के रूप में आसानी से याद कर सकते हैं, जबकि ..= निश्चित रूप से अधिक बाहर खड़ा है और जीता है यह समस्या नहीं है।

मुझे यकीन नहीं है कि मुझे सौंदर्य की दृष्टि से ..= सिंटैक्स पसंद है, लेकिन मैं देख सकता हूं कि हर कोई लगभग .. और ... बहुत समान रूप से पढ़ रहा है।

@zengsai क्योंकि = बनाम == में एक समाधान है जो .. बनाम ... ।

ज़रूर, आप सी में = और == को भ्रमित कर सकते हैं ...

1. यदि आप टाइप यह एक त्रुटि है if x = y बजाय if x == y (इस सुधार में जंग और अजगर बना है)
2. जब मैंने गलती से x == y; बजाय x = y; टाइप कर दिया, तो मुझे एक ऐसे व्यंजक के बारे में चेतावनी मिली जिसका कोई प्रभाव नहीं है।

कंपाइलर के लिए यह भी पहचानने का कोई तरीका नहीं है कि .. बनाम ... भ्रम गड़बड़ है , गलत होने दें।

@zengsai .. और ... उन प्रकारों का मूल्यांकन करते हैं जो सभी समान लक्षणों को लागू करते हैं और अनिवार्य रूप से एक दूसरे के लिए उपयोग किया जा सकता है (यह डिज़ाइन द्वारा है)। एक के बाद एक त्रुटि एक बहुत ही वास्तविक मुद्दा है।

मैं स्पष्ट करना चाहता हूं कि मैं भी इस वाक्य रचना से नफरत करता हूं, इतना कि मैं @aturon की टिप्पणी से सहमत नहीं हूं कि वर्तमान स्थिति जहां हम .. और अभिव्यक्तियों और ... का उपयोग करते हैं पैटर्न "अस्थिर" है; वास्तव में, मुझे लगता है कि इस सिंटैक्स की तुलना में डिस्कनेक्ट होना बेहतर है।

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

यदि मेरे अनुभव में इसका कोई सांत्वना है तो अधिकांश उपयोग मामलों को वास्तव में इस सुविधा की आवश्यकता नहीं है, और इसलिए यह आपके पूरे कोड में दिखाई नहीं देगी।

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

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

@ssokolow क्षमा करें, मैं अभी भी आपसे सहमत नहीं हो सकता। कंपाइलर आपको इस प्रकार के टाइपो की चेतावनी दे सकता है, लेकिन क्या होगा यदि आप "x=5" टाइप करते हैं जहां यह "x=6" होना चाहिए?

टाइपो से बचने के लिए कंपाइलर सही नहीं है, प्रोग्रामर है।

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

आज की जंग पहले से ही पढ़ने और लिखने की समस्या का सामना कर रही है, जितना अधिक असामान्य और प्रतिवादात्मक वाक्यविन्यास जितना अधिक सीखने की अवस्था होगी, इसे एक और पर्ल न बनाएं।

@withboats हम इसके साथ बहस करते हैं, क्योंकि हम इसे प्यार करते हैं। शायद इस तर्क में बहुत देर हो चुकी है, और कुछ भी नहीं बदल सकता, बस...

@zengsai

निश्चित रूप से ट्रेड-ऑफ किए जाने हैं, लेकिन मुझे लगता है कि हम उन दोनों के बीच सर्वोत्तम संतुलन बिंदु पर कभी सहमत नहीं होंगे।

व्यक्तिगत स्वाद के बावजूद, मैं ..= को एक छोटी सी कीमत के रूप में देखता हूं जिससे बचने के लिए बग को ट्रैक करने की कोशिश में बहुत बड़ी मात्रा में समय बर्बाद हो सकता है।

(मेरा फोकस का क्षेत्र UI/UX डिज़ाइन है और सबसे बड़े नियमों में से एक है जो वे आपको सिखाते हैं कि आपको गलती करने में आसानी को नुकसान और/या समय-समय पर ठीक करने के लिए आनुपातिक रूप से आनुपातिक बनाने का लक्ष्य बनाना चाहिए। )

मेरी छोटी राय में, 5 बनाम 6 .. बनाम ... तुलना में अधिक स्पष्ट है।

@zengsai मुझे इस बातचीत के लिए बहुत सारे ईमेल प्राप्त हो रहे हैं, अपनी भावनाओं को बेहतर ढंग से व्यक्त करने के लिए IRC चैनल को रस्ट करने के बारे में कैसे जाना जाए?

@daiheitan यह एक सामान्य संचार है। अगर आपको यह पसंद नहीं है, तो मेरा सुझाव है कि आप इस ईमेल की अपनी

जब मैंने पहली बार रस्ट को देखा, तो मैं वास्तव में .. सिंटैक्स के बारे में हैरान था। (1..10).sum() है... 1 से 9 तक के पूर्णांकों का योग? यदि आप किसी नवागंतुक को यह वाक्य-विन्यास प्रस्तुत करते हैं और उससे पूछते हैं कि इसका क्या अर्थ है, तो इसकी बहुत संभावना है कि वह इसे 1 से 10 तक जाने की उम्मीद करेगा। और वह ऐसा करने के लिए सही होगा, क्योंकि आप सममित वाक्य-विन्यास से सममिति को व्यक्त करने की अपेक्षा करेंगे। पर्वतमाला। 1 को क्यों शामिल किया जाना चाहिए लेकिन 10 को नहीं?

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

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

@rkarp कुछ हद तक, यह शायद पहले से मौजूद पूर्वाग्रह के लिए नीचे है।

उदाहरण के लिए, रस्ट में बहुत अधिक पायथन प्रभाव होता है और पायथन उसी तरह की आधी-खुली श्रेणियों का उपयोग करता है। (यानी। पायथन के range(1, 5) या myList[1:5] दोनों का व्यवहार रस्ट के 1..5 के समान ही है)

पायथन में इसके लिए औचित्य केवल एक सिंटैक्स होने से जुड़ा था और आधे-खुले सिंटैक्स ने head, tail = myList[:pivot], mylist[pivot:] जैसी चीजों को करना आसान बना दिया।

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

..= काम करता है क्योंकि आप .. (अनन्य) और ..= (समावेशी) को हर जगह स्वीकार कर सकते हैं और ... को .. लिए पदावनत पर्याय के रूप में मान सकते हैं। पैटर्न में।

केवल यह कहना, टोकन के रूप में ..= होना तकनीकी रूप से एक असंगत परिवर्तन है, क्योंकि यह मैक्रोज़ में :tt नियमों को प्रभावित करता है। शायद कोई समस्या नहीं होगी, लेकिन आप यह सुनिश्चित करने के लिए जांच कर सकते हैं कि क्या कोई ऐसा नहीं करता है, यह देखते हुए कि यह एक शांत बदलाव भी हो सकता है। (विकल्प .. /* why not */ = अनुमति दे रहा है, जो मुझे नहीं लगता कि यह एक अच्छा विचार है)

@ssokolow तकनीकी रूप से, यह रस्ट में टाइप एरर है, पार्स एरर नहीं। a = 2 एक अभिव्यक्ति है जो () लौटाती है, और if bool अपेक्षा करती है, इसलिए वे स्पष्ट रूप से असंगत हैं।

धीरे-धीरे नियम बदल रहे हैं। तकनीकी रूप से ..= 3 टोकन हैं जहां पहले 2 के बाद कोई स्थान नहीं है।

@eddyb : मैं मानता हूं, मैं इसे पूरी तरह समझ नहीं पा रहा हूं। क्या बिना प्रभावित किए एक नया टोकन पेश करने का कोई तरीका है: tt इसे कैसे पार करता है?

यह कोड वर्तमान में "नियम 2" और "नियम 4" की रिपोर्ट करता है। यह परिवर्तन अगर मैं इसे सही ढंग से समझता हूं तो इसे "नियम 2" और "नियम 5" में बदल दिया जाएगा।

macro_rules! ex {
    ( . . )   => { "Rule 1: . ." };
    ( .. )    => { "Rule 2: .."};
    { . . = } => { "Rule 3: . . = " };
    { .. = }  => { "Rule 4: .. = " };
    { ..= }   => { "Rule 5: ..=" };
}

macro_rules! show {
    ( $($t:tt)* ) => { println!("{}", ex!($($t)*)) };
}

fn main() {
    show!(..);
    show!(..=);
}

नहीं, यह एक बदलाव है कि टोकन को कैसे परिभाषित किया जाता है। @jseyfried परिणामों को बेहतर तरीके से समझा सकता है।

तकनीकी रूप से, यह रस्ट में टाइप एरर है, पार्स एरर नहीं। ए = 2 एक अभिव्यक्ति है जो () लौटाती है, और यदि बूल की अपेक्षा है, तो वे स्पष्ट रूप से असंगत हैं।

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

मैंने अपनी टिप्पणी समायोजित कर ली है।

मुझे ..= सिंटैक्स पसंद नहीं है और मैं पैटर्न में ... को पदावनत करने के खिलाफ हूं। यदि हम टाइपो त्रुटि से डरते हैं, तो हम इसके शॉर्टहैंड के लिए ... या ..= के बजाय हमेशा RangeInclusive { start, end } संरचना का उपयोग कर सकते हैं।

संभावित अस्पष्टता जिसे मैंने अभी महसूस किया है:

if let 5..=x { ... }

@clarcharr ऐसा लगता है कि हालांकि यह संकलित नहीं है।

rustc 1.17.0 (56124baa9 2017-04-24)
error: unexpected token: `=`
 --> <anon>:3:13
  |
3 |     if let 5..=x {
  |             ^^

error: aborting due to previous error

@clarcharr @kennytm
जब हम एक ऑपरेटर के रूप में ..= पेश करते हैं, तो त्रुटि होगी:

error: expected one of `::` or `=`, found `{`
 --> <anon>:3:13
  |
3 |     if let 5..=x {
  |                  ^

error: aborting due to previous error

अभी की तरह let x=10; if let 5..x {}

तो यह "अस्पष्टता" संकलित नहीं होगी और इस प्रकार if let 5..x {} से अधिक अस्पष्टता नहीं होगी।

@Boscop बिंदु यह है कि, वर्तमान में यदि हम 5.. को Some(5) जैसे पैटर्न के रूप में देखते हैं, तो if let 5.. = x समान होगा let Some(5) = x , और बाद वाला संकलन। मेरे टिप्पणी से पता चलता है कि 5.. एक पैटर्न नहीं है, इसलिए वहाँ से कोई संगतता खतरा है if let शुरू करने के लिए ..= ।

अगर हम इस सुविधा को पेश करते हैं और पैटर्न में ..= और .. दोनों की अनुमति देते हैं, तो if let 5..=x हमेशा if let 5.. = x होना चाहिए और इसे संकलित करना चाहिए: if let (single expression) कोई मतलब नहीं है, इसलिए मुझे विश्वास नहीं है कि कोई अस्पष्टता है।

@kennytm तो हम दोनों ने 2 अलग-अलग अस्पष्टताओं के लिए दिखाया कि वे संकलित नहीं होंगे। (यह स्पष्ट नहीं था कि उनका क्या मतलब था। यह थोड़े अस्पष्ट था, हे।)

@daboross Like kennytm ने कहा, 5.. एक पैटर्न नहीं है और अब भी संकलित नहीं करता है। और अगर हम एक ऑपरेटर के रूप में ..= जोड़ते हैं तो यह नहीं बदलेगा। कोई अस्पष्टता नहीं है। महत्वपूर्ण बात यह है कि अब, ..= को एक ऑपरेटर के रूप में पार्स नहीं किया जा सकता है, लेकिन एक बार हम इसे एक ऑपरेटर के रूप में पार्स कर सकते हैं, तो कोई अस्पष्टता नहीं है।

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

इसलिए जब वर्तमान व्याकरण पर विचार किया जाता है तो @ clarcharr का अवलोकन अस्पष्टता को इंगित नहीं कर रहा है, संभावित भविष्य के विस्तार पर विचार करते समय यह निश्चित रूप से एक अस्पष्टता है जो पैटर्न के लिए ..= का उपयोग करने के प्रस्ताव के साथ संघर्ष कर सकता है।

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

(यह एक और कारण है कि मुझे लगता है कि संरचना को स्थिर करने के लिए आगे बढ़ना एक अच्छा विचार है, और बाद में वाक्यविन्यास।)

@nagisa if let संबंध में कोई विरोध नहीं है यदि रेंजफ्रॉम पैटर्न समर्थित होने से पहले टोकन ..= जोड़ा जाता है। कोई भी .. और = बीच एक स्थान जोड़ सकता है, जैसे x <- y (प्लेसमेंट इन) बनाम x < -y (+ नकारात्मक से कम)।

(चूंकि ^ अनन्य -या ऑपरेटर है, ^ मुझे समावेशी श्रेणी के लिए ..^ का उपयोग करना विडंबनापूर्ण लगता है)

मेरे द्वारा लिखी गई हज़ारों श्रेणियों में, उनमें से कुछ पूरी तरह से बंद हैं, शायद एक या दो आधे-अधूरे रास्ते गलत तरीके से खुले हैं, मुझे अभी भी वास्तव में किसी अतिरिक्त वाक्यविन्यास की आवश्यकता नहीं दिख रही है। 1..(n+1) लिखना इतना कठिन नहीं है।

यह अंत = टी :: max_value() के लिए काम नहीं करता है।

29 मई, 2017 को 16:33 पर, "डिगरी हार्डी" नोटिफिकेशन @github.com ने लिखा:

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

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

मैं आधा बंद श्रेणियों पर ..= हालांकि एक विधि पसंद करूंगा।

29 मई 2017 को 16:35 को, "साइमोनस कज़लौस्कस" [email protected] ने लिखा:

यह अंत = टी :: max_value() के लिए काम नहीं करता है।

29 मई, 2017 को 16:33 पर, "डिगरी हार्डी" नोटिफिकेशन @github.com ने लिखा:

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

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

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

यह अंत = टी :: max_value() के लिए काम नहीं करता है।

क्या आप वाकई 2^64 मानों या 2^8 मानों से अधिक पुनरावृति करना चाहते हैं? यदि आप केवल पिछले कुछ मानों जैसे u32 पर पुनरावृति करना चाहते हैं, तो लूप के अंदर एक जोड़ना अक्सर आसान होता है। और यदि आप वास्तव में किसी अस्पष्ट कारण से 2^B-1 पर पुनरावृति करना चाहते हैं, तो आप लूप के अंत में हमेशा if i == END { break; } चिपका सकते हैं।

सिर्फ इसलिए कि हमारे मानक अहस्ताक्षरित पूर्णांक 2^32 या 2^64 मानों का समर्थन करते हैं, इसका मतलब यह नहीं है कि उच्चतम प्रतिनिधित्व योग्य मूल्य बहुत बार उपयोग किया जाता है। और यदि आप u8 साथ कुछ कर रहे हैं, तो यह न भूलें कि सीपीयू के लिए काउंटर के लिए u32 का उपयोग करना शायद आसान है।

लेकिन अगर मुझे क्लोज्ड रेंज जनरेटर सिंटैक्स की आवश्यकता नहीं दिखती है, तो भी मैं परिवर्तन के लिए टीम के तर्कों का खंडन नहीं कर सकता। ओह अच्छा :/

इन चारों के बारे में सभी समावेश विकल्पों को कैसे शामिल किया जाए?

1...10
1>..10
1..<10
1>.<10

मुझे लगता है कि किसी को यह समझने में सक्षम होना चाहिए कि वे आगे स्पष्टीकरण के बिना क्या कहते हैं, यह देखते हुए कि असमानता ऑपरेटरों को किंडरगार्टन से हर किसी के दिमाग में अंकित किया गया है ... पता नहीं है कि ये अन्य तरीकों से दर्द होगा, हालांकि।

वैकल्पिक रूप से, हम असमानताओं को बदल सकते हैं:

1...10
1<..10
1..>10
1<.>10

... बस इसलिए कि आखिरी वाला नाराज कार्टमैन की तरह न दिखे।

@vegai और मौजूदा a..b सिंटैक्स के बारे में क्या जो निश्चित रूप से हटाया नहीं जा रहा है? नहीं, मुझे नहीं लगता कि नए सिंटैक्स विकल्पों का सुझाव देने से कुछ भी हल हो जाएगा।

हम्म, इसलिए दो "संभावित अस्पष्टताएं" उठाई गई हैं:

• if let 5..= x -- जैसा कि कहा गया है, यह वास्तव में अब अस्पष्टता नहीं है, लेकिन यह एक तरह से हो सकता है। दूसरी ओर, इस प्रकार की अस्पष्टता अक्सर उत्पन्न होती है, और टोकननाइज़र द्वारा संबोधित किया जाता है। अर्थात्, यदि हम अपने पार्सर में ..= को एक टोकन के रूप में मानते हैं, तो यह अस्पष्ट नहीं है, भले ही हम भविष्य में 5.. पैटर्न जोड़ दें; आपको बस .. और = (जैसे, let 5.. = x ) के बीच एक स्पेस लिखना होगा।
• मैक्रो-नियमों के संबंध में अस्पष्टता। यह वास्तव में एक दर्द और दुर्भाग्यपूर्ण है, और यह एक कारण है कि हम "मैक्रोज़ 2.0" के लिए एक अलग सिस्टम की ओर बढ़ रहे हैं, जहां हम एंड-यूज़र के लिए "कंपाउंड टोकन" के सेट को उजागर करने से बचते हैं।
  
  
  
  • अंत में, यदि आवश्यक हो तो हम कुछ विशेष-केस कोड के माध्यम से macro_rules! back-compat को संभाल सकते हैं; किसी भी मामले में, मुझे लगता है कि ... का उपयोग करने के अलावा इस तरह की समस्या से बचने का कोई तरीका नहीं है।
  
  

समावेशी श्रेणियों को स्थिर करने से पहले, समस्या # 42401 को भी इमो तय किया जाना चाहिए, क्योंकि स्थिरीकरण के बाद फिक्स एक ब्रेकिंग परिवर्तन होगा।

@ est31 अच्छा बिंदु, मैंने इसे मुद्दे के शीर्ष पर चेकलिस्ट में जोड़ा

चेक किया गया str स्लाइसिंग अपने आप में अस्थिर है और उस समस्या को ठीक करना समावेशी श्रेणियों को बिल्कुल भी अवरुद्ध नहीं करता है।

ओह, @nagisa सही है, इसका रेंज सिंटैक्स से कोई लेना-देना नहीं है। क्या आप इसे फिर से सिर से हटा सकते हैं? मेरी गलती। बग बल्कि get के कार्यान्वयन में है, और इसलिए str_checked_slicing सुविधा द्वारा संरक्षित है:

    impl SliceIndex<str> for ops::RangeToInclusive<usize> {
        type Output = str;
        #[inline]
        fn get(self, slice: &str) -> Option<&Self::Output> {
            if slice.is_char_boundary(self.end + 1) {
                Some(unsafe { self.get_unchecked(slice) })
            } else {
                None
            }
        }
    [...]

निकाला गया

एक और चेकबॉक्स अपडेट: पीआर https://github.com/rust-lang/rust/pull/42134 ने https://github.com/rust-lang/rfcs/pull/1980 ट्वीक लागू किया

टक्कर: किसी भी तरह से हम 1.20 के लिए कम से कम structs को स्थिर कर सकते हैं?

हम समावेशी श्रेणी सिंटैक्स के लिए प्रसिद्ध गो-टू ऑपरेटर को C++ से कैसे उधार लेते हैं? मैं

@nikomatsakis और @

cc @rust-lang/libs (केवल एक टीम के लोग ही अपनी या अन्य टीमों को टैग कर सकते हैं)

धन्यवाद, @eddyb!

@clarcharr https://github.com/rust-lang/rust/pull/42275#discussion_r119211211 पर आधारित, मुझे संदेह है कि इसकी सराहना की जाएगी।

क्या मुझे वाक्य रचना प्रस्ताव के लिए ट्रेन के लिए बहुत देर हो चुकी है?
करंट ऐसा लगता है जैसे कोई स्लाइस को मान निर्दिष्ट करने का प्रयास करता है।

for i in a..b {} // [a..b) 
for i in a..+b {} //[a..b] 
for i in a-..b {} //(a..b) 
for i in a-..+b {} // (a..b]

यह सिंटैक्स भविष्य में श्रेणियों के लिए किसी भी Add कार्यान्वयन को जोड़ना असंभव बना देगा। मैं वास्तव में नहीं जानता कि क्या यह एक समस्या है, हालांकि मुझे वास्तव में यकीन नहीं है कि Add कार्यान्वयन क्या करेगा।

अनुगामी प्लस के लिए सहमत हैं। उपसर्ग में बदल दिया।

क्योंकि a.. , ..b और .. जंग में मान्य निर्माण हैं, यह अभी भी गणितीय कार्यों के साथ अस्पष्टता पैदा करता है: /

a... / a..= / a..+ सही हालांकि मान्य नहीं होगा? चूंकि एक असीमित सीमा होने के बाद अंत बिंदु शामिल होना वास्तव में समझ में नहीं आता है।

मैं Add बारे में बहुत चिंतित नहीं होगा, ऐसा नहीं लगता कि यह श्रेणियों के साथ करने के लिए बहुत आम होगा, और यदि आप चाहते हैं, तो आप (x..+y) + z ?

संपादित करें: कोई बात नहीं, बस एहसास हुआ कि आपका क्या मतलब है। यह a..+b जो अस्पष्ट होगा, है ना? चूंकि अभी इसका मतलब है a.. + b ।

@daboross यह नहीं कह रहा है कि यह एक अच्छा या बुरा विचार है, लेकिन यह कार्यान्वयन (या इस पर कुछ बदलाव) कुछ ऐसा हो सकता है जिसे हम भविष्य में श्रेणियों के लिए चाहते हैं:

impl<T> Add<T> for RangeFrom<T> where T: Add<T> {
    type Output = RangeFrom<T>;
    fn add(self, rhs: T) -> RangeFrom<T> {
        (self.start + rhs)..
    }
}

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

मेरी दूसरी चिंता यह है कि ... को खारिज करने का पूरा बिंदु टाइपो को पहचानने में कठिनाई की संभावना को कम करना है और माता-पिता को अमूर्त a..+b दो अलग-अलग अर्थों के बीच अंतर करने की अनुमति देना ऐसा लगता है। उस दिशा में वापस जा रहे होंगे।

इसके अलावा, मुझे अभी तक a-..b और a-..+b के लिए "पूर्णता के लिए अच्छा नहीं होगा" से परे एक ठोस औचित्य देखना बाकी है, जबकि वर्तमान .. और प्रस्तावित ..= दोनों को ज्ञात, मान्य तर्क हैं।

आप इसके लिए + उपयोग नहीं कर सकते क्योंकि यह एक्सप्रेशन सिंटैक्स को अस्पष्ट बनाता है।

संपादित करें: हालांकि, मुझे लगता है, यह पूरी तरह से पुस्तकालय में समावेशी श्रेणियों को लागू करना संभव बना देगा, क्योंकि आप <Range as Add<{integral}>>::Output = InclusiveRange कार्यान्वयन को समाप्त कर देंगे।

मैं ..! प्रकार का सुझाव दे सकता हूं। इसमें .. साथ उत्पादक तुकबंदी है और अंतिम बिंदु पर अतिरिक्त जोर देता है जिससे यह अधिक ध्यान देने योग्य हो जाता है।

बेशक यह ऑपरेटर ! टकराएगा लेकिन, ईमानदारी से कहूं तो, मैं उस स्थिति की कल्पना नहीं कर सकता था जहां किसी को ! को बाध्य उप-अभिव्यक्ति में डालने की आवश्यकता होगी।

..! में सहजता की समस्या है। एक नवागंतुक जो अभी तक वाक्य रचना से परिचित नहीं है, आसानी से ..! का अर्थ "अप करने के लिए, लेकिन नहीं ..." को आसानी से गलत समझ सकता है।

यह "रेंज अप टू बिटवाइज कॉम्प्लीमेंट..." के सिंटैक्स से भी टकराता है (जो इसे + का उपयोग करने जैसी स्थिति में डाल देगा)

सहमत। लेकिन दूसरी ओर ..= को असाइनमेंट ऑपरेटरों में से एक के रूप में भी गलत समझा जा सकता है।

यदि यह एक असाइनमेंट ऑपरेटर होता तो आप क्या असाइन करते?

@ snuk182 के प्रस्ताव के आधार पर:

a...b // [a; b] shorthand for RangeIncusive
a..-b // [a; b) new Range shorthand 
a..b // [a; b) old Range shorthand exists for compatibility

मुझे संदेह है कि क्या हमें अन्य संयोजनों की आवश्यकता है। किसी भी स्थिति में, इसे बाद में जोड़ा जा सकता है:

a-..b // (a; b]
a-.-b // (a; b)  

हालांकि आखिरी विकल्प थोड़ा अजीब लगता है। ^_^

कृपया किसी भी सिंटैक्स का प्रस्ताव देना बंद करें जिसमें एक यूनरी ऑपरेटर हो, जैसे a..-b , a..!b , a..*b , a..&b या a?..b , ये कभी नहीं होंगे स्वीकार किए जाते हैं।

..! अंतर्ज्ञान के साथ समस्या है। एक नवागंतुक जो अभी तक वाक्य रचना से परिचित नहीं है, आसानी से गलत समझ सकता है ..! का अर्थ है "अप करने के लिए, लेकिन नहीं ..."

..= में सहजता के साथ एक ही समस्या है। जो कोई भी = देखता है, वह प्रभाव या तुलना की अपेक्षा करता है। मैं स्वीकार करता हूं कि यह सिंटैक्स पूरी तरह से अलग-अलग समस्या को हल करता है क्योंकि हर बार जब मैं ..= देखता हूं, तो मैं खुद को यह सोचने से नहीं रोक सकता कि यह समान चिह्न यहां क्या कर रहा है।

एकमात्र प्रस्तावित सिंटैक्स जो वर्तमान सिंटैक्स के साथ बहुत सहज और सुसंगत दोनों है ... । लेकिन ऐसा लगता है कि जहाज रवाना हो गया है।

नवागंतुकों को वैसे भी दस्तावेज़ों को बार-बार देखना होगा। यहां तक ​​कि ... वे डॉक्स को देखेंगे। यह टालने योग्य नहीं है। लेकिन ..= में एक अच्छा निमोनिक ( up to और equal to ) है, इसलिए उन्हें इस ऑपरेटर के दस्तावेज़ों को बार-बार देखने की आवश्यकता नहीं होगी।

क्या होगा यदि ... ऑपरेटर जैसा है वैसा ही रहेगा, लेकिन इसके बजाय हम .. ऑपरेटर को ..⎵ , यानी दो बिंदु और एक स्थान (मुझे वह रखना था '⎵ ' वहाँ चरित्र है क्योंकि इस वेबपेज पर एक नियमित स्थान नहीं दिखाई देगा)। यह भाषा में एकमात्र स्थान होगा जहां सफेद स्थान मायने रखता है। यह एक ब्रेकिंग बदलाव भी होगा, क्योंकि a..b जैसे सभी कोड शिकायत करेंगे कि .. जैसा कोई ऑपरेटर नहीं है, और डॉट्स के बाद कम से कम एक स्थान जोड़ने की सलाह है। मुझे लगता है कि अंतरिक्ष उन्हें दृष्टि से पर्याप्त रूप से अलग बनाता है:

a.. b
a...b

@tommit मुझे नहीं लगता कि ईमानदार होना एक अच्छा विचार होगा।

सफेद रिक्त स्थान के संबंध में ऑपरेटर वर्तमान में काफी लचीला है, उदाहरण के लिए: a..b और a .. b समान हैं। यह संभवतः इसे अन्य ऑपरेटरों, जैसे a+b और a + b अनुरूप बनाने के लिए है। ये निश्चित रूप से वही करते हैं, और लोगों को विभिन्न वाक्यविन्यास शैलियों का उपयोग करने की अनुमति देते हैं। अगर आप मुझसे पूछें तो यह अच्छी बात है!

इसे जोड़ने के लिए, ..= नोटेशन <= और >= नोटेशन (जिन्हें _inclusive_ भी माना जाता है) के अनुरूप है।

यह जांचना हमेशा अच्छा होता है कि अन्य संभावनाएं क्या हैं, लेकिन यह शायद सही समाधान नहीं है।

सहमत। <= और >= , ..= प्रशंसनीय लगता है, यहां तक ​​कि तार्किक भी।

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

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

किसी भी मामले में, वास्तविक वाक्यविन्यास के बारे में अभी भी बहुत सारे बाइकशेड चल रहे हैं। मैंने कम से कम संरचनाओं और लक्षणों और निहितार्थों को स्थिर करने के लिए # 43086 दायर किया है ताकि मुख्य कार्यक्षमता का उपयोग किया जा सके (मांग लगती है, ऊपर @ retep998 द्वारा टिप्पणी देखें)।

कमरे में हाथी यह है कि .. वास्तव में इसके सममित रूप लेकिन असममित अर्थ के कारण यहां वास्तविक समस्या है। "करने के लिए सही काम" शायद इसे बहिष्कृत कर देगा, लेकिन ऐसा करने की कोई इच्छा नहीं है क्योंकि इतना कोड पहले से ही इसका उपयोग करता है।

पूरी तरह से सुसंगत ... (सममित रूप, सममित अर्थ) को हटाना आसान तरीका है, लेकिन ..= में एक और असंगत ऑपरेटर जोड़ने की कीमत पर। ऐसा लगता है कि पिछले खराब डिज़ाइन के आसपास काम करने के लिए खराब डिज़ाइन जोड़ना।

इस दोहरी असंगति के कारण इसके साथ एक और समस्या है: अंतिम दो शेष समावेशन प्रकारों को जोड़ने का कोई अच्छा तरीका नहीं है (दोनों पक्षों के लिए अनन्य और केवल बाईं ओर अनन्य)। चूंकि .. और ..= दोनों में पहले से ही बाईं ओर एक अंतर्निहित = होगा, इसलिए हमें इसे किसी भी तरह से अस्वीकार करना होगा, संभवतः < । तो उन्हें कुछ इस तरह दिखना होगा:

• <..= लिए (a; b]
• <.. लिए (a; b)

गुड लक सही ढंग से अनुमान लगा रहा है कि एक नवागंतुक के रूप में इनका क्या अर्थ है। तो वे शायद (सही ढंग से) कभी भी जोड़े जाने पर विचार नहीं करेंगे।

यदि .. इतना गहरा नहीं था या अस्तित्व में भी नहीं था, तो खरोंच से इस सब के लिए एक सुसंगत डिजाइन के साथ आना इतना कठिन नहीं लगता, उदाहरण के लिए:

• .. (या ... ) [a; b]
• ..< लिए [a; b)
• <.. लिए (a; b]
• <..< लिए (a; b)

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

_संपादित करें: अधिक स्पष्टता के लिए एक उदाहरण और कुछ टिप्पणियां जोड़ी गईं।_

मैं @rkarp से सहमत हूं कि .. यहां वास्तविक समस्या है, ... या ..= । असममित अर्थ विशेष रूप से बुरा है क्योंकि अन्य (अधिक लोकप्रिय) भाषाएं वास्तव में इसे एक सममित अर्थ प्रदान करती हैं। उदाहरण के लिए कोटलिन, रूबी और हास्केल दोनों 5 को 3.5 की सीमा में मानते हैं। गणित के पेपर भी इसके पक्ष में नजर आ रहे हैं। यहां सबसे बुरी बात यह है कि शुरुआती लोगों के पास रस्ट में 3.5 के व्यवहार का अनुमान लगाने का कोई मौका नहीं है: आप या तो तय करेंगे कि 4 और केवल 4 रेंज 3.5 (डॉट्स पर पुनरावृत्ति) का सदस्य है या दोनों इसमें 3 और 5 भी हैं ('सब कुछ जो हम देख सकते हैं' और डॉट्स के एक्सट्रपलेशन पर पुनरावृति)।

हालांकि मैं इसे बदलने की कठिनाई पर असहमत हूं। मुझे लगता है कि @adelarsq सुझाव अपेक्षाकृत दर्द रहित तरीके से लागू किया जा सकता है। सन्दर्भ के लिए:

[1..4] // 1, 2, 3, 4
[1..4[ // 1, 2, 3
]1..4] // 2, 3, 4
]1..4[ // 2, 3

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

https://github.com/rust-lang/rust/issues/28237#issuecomment -274216603 यह कोई नया विचार नहीं है और हम इसका उपयोग उन कारणों से नहीं कर सकते हैं जिनका हमने पहले ही उल्लेख किया है।

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

कई अन्य प्रस्ताव हैं जो काम कर सकते हैं। उदाहरण के लिए, मैंने ..@ प्रस्तावित नहीं देखा है, और x..@y विचारोत्तेजक प्रतीत होता है। अस्पष्टता की कमी को बनाए रखते हुए, वर्तमान प्रस्ताव की तुलना में कुछ अधिक सम्मोहक खोजने की चुनौती है।

मैं समरूपता के अपने पसंदीदा दृश्य के रूप में 2 महीने पहले @ssokolow की टिप्पणी को हाइलाइट करना चाहता था:

• ..4 में चीजें शामिल हैं < 4
• ..=4 में चीजें शामिल हैं <= 4

मुझे लगता है कि हमें केवल समावेशी श्रेणी की आवश्यकता है, यह अधिक सरल है।
श्रेणी बदलने के लिए आप हमेशा + 1 या -1 जोड़ सकते हैं।
और..बेहतर है, क्योंकि..से आसान है...!

@AlexanderChen1989 जैसा कि इस थ्रेड पर पहले कई पोस्ट में कहा गया है, यह संभव नहीं है क्योंकि .. का अर्थ बदलने से मौजूदा कोड टूट जाएगा।

इसके अलावा, यह वास्तव में इतना आसान नहीं है। सबसे विशेष रूप से, +1 और -1 पूर्णांक अतिप्रवाह/अंडरफ्लो का कारण बन सकते हैं।)

यहां एक उदाहरण दिया गया है जो nightly (समावेशी श्रेणी सिंटैक्स के लिए पुराने उम्मीदवार के माध्यम से) में काम करता है, जहां...

• ...आप जो भी लूप पहले डालते हैं वह डिबग बिल्ड में अतिप्रवाह/अंडरफ्लो से घबराएगा
• ...वे रिलीज़ बिल्ड में इच्छित के बिल्कुल विपरीत व्यवहार करेंगे (अर्थात "0 से 0" 256 बार पुनरावृति करेगा और "0 से 255" बिल्कुल भी पुनरावृति नहीं करेगा)

#![feature(inclusive_range_syntax)]
fn main() {
    let max = 255u8;
    let user_provided = 0u8;

    for x in 0...user_provided-1 {
        println!("(0 to 0, exclusive via 'inclusive - 1'): {}", x);
    }

    for x in 0..max+1 {
        println!("(0 to 255, inclusive via 'exclusive + 1'): {}", x);
    }
}

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

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

यह केवल उन चीजों के बारे में बात करनी चाहिए जो वर्तमान योजना को स्थिर करने के लिए किए जाने की आवश्यकता है।

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

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

@ बैडेल 2 कूल। मैंने वास्तव में शुरुआत कर दी है -- मैं जल्द ही अपनी शाखा को आगे बढ़ाऊंगा और इसे यहां लिंक करूंगा।

@durka सिर्फ स्पष्ट करने के लिए - क्या आप @ Badel2 को अपनी शाखा से शुरू करने की पेशकश कर रहे हैं? क्या आप उन्हें निहित अवधि के काम के हिस्से के रूप में सलाह दे सकते हैं? वे Gitter चैनल में हैं।

मैं यह भी मानता हूं कि वास्तविक समस्या .. । तो, अधिक अनुकूल समाधान बहिष्कृत कर रहा है (एक बार में प्रतिस्थापित नहीं कर रहा है, इसलिए यह मौजूदा कोड को तोड़ देगा) .. ..< जैसी किसी चीज़ के पक्ष में ( a..<b बीच कोई भ्रम नहीं होगा) (a..)<b , क्योंकि .. का अस्तित्व समाप्त हो जाएगा)।

@ hyst329 कृपया पहले से बनी पोस्ट को पढ़ें।

पहली पोस्ट बोल्डफेस टेक्स्ट में कहती है, "इस थ्रेड में कोई और सिंटैक्स चर्चा नहीं होनी चाहिए।"

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

क्षमा करें, यह बहुत रचनात्मक नहीं है, लेकिन हर बार जब मैं ..= देखता हूं और यह याद रखने की कोशिश करता हूं कि यह क्या है, तो यह += या <<= समान असाइनमेंट ऑपरेटर जैसा दिखता है। यह बहुत भ्रमित करने वाला लगता है कि ऐसा नहीं है। (हालांकि माना जाता है कि यह संदर्भ से बाहर है, उदाहरण के लिए " ..= सिंटैक्स के लिए प्रारंभिक समर्थन" https://this-week-in-rust.org/blog/2017/10/03/this-week- इन-जंग-202/)

@SimonSapin मैंने ऊपर और अधिक रचनात्मक फैशन में उसी आलोचना को व्यक्त किया है, इसके बजाय ..^ सुझाव दिया है: https://github.com/rust-lang/rust/issues/28237#issuecomment -304325663

मेरे लिए, एक बड़ा मुद्दा यह है कि के लिए बोलता है ..= तेज के साथ संगति तरह-की (जो है ..< विशेष के लिए और .. समावेशी श्रेणियों के लिए)। इसने मुझे ..= की पसंद के साथ ठीक कर दिया।

@SimonSapin मुझे नहीं लगता कि ऐसा कोई है जो इससे पूरी तरह खुश है। समस्या यह है कि सैकड़ों टिप्पणियों ने दुर्भाग्य से पुष्टि की है कि कोई बेहतर विकल्प नहीं है।

कुछ भी नहीं करने की तुलना में मुझे समझाने के लिए हासिल किया गया यह पैच केवल किनारे के मामलों को कवर करने के लिए मौजूदा पैटर्न सिंटैक्स को गड़बड़ाने से बेहतर है।

.. पैटर्न में बहुत कम उपयोग के मामले हैं और आप हमेशा इसके बिना सौदा कर सकते हैं।

... को RangeInclusive या (Bound<T>, Bound<T>) उन भावों में बदला जा सकता है जिनकी वास्तव में उन्हें आवश्यकता होती है। यह अधिक वर्बोज़ है लेकिन समझने में आसान है।

@UtherII

... और मैं आश्वस्त था कि ... संकलक के "आप स्थिर पर समावेशी श्रेणी वाक्यविन्यास का उपयोग नहीं कर सकते" संदेश द्वारा सूक्ष्म बग से सहेजे जाने के समय तक अस्थिर है।

जब आप तेजी से लगातार कई बार दबा रहे हों तो गलती से . एक बार बहुत अधिक (या, शामिल यांत्रिकी को देखते हुए, एक बार बहुत कम) हिट करना बहुत आसान है।

मैंने "बदलाव को स्वीकार करने के लिए ..= को पैटर्न में ... पर्याय के रूप में और अभिव्यक्तियों में ..= को स्वीकार करने के लिए चेक किया है क्योंकि यह पहले से ही #44709 के बाद के मामले में है क्रमशः dotdoteq_in_patterns और inclusive_range_syntax सुविधाएँ। जो कुछ बचा है वह सिर्फ दस्तावेज़ीकरण और स्थिरीकरण है।

स्थिरीकरण के लिए अनुरोध

मैं समावेशी सीमा को 1.26 (30 मार्च को बीटा, 11 मई को स्थिर) या इससे पहले स्थिर करना चाहता हूं। एक स्थिरीकरण पीआर #47813 के रूप में प्रस्तुत किया गया है।

सारांश

निम्नलिखित 3 सुविधाओं को स्थिर किया जाएगा:

• inclusive_range_syntax — एक व्यंजक में a..=b और ..=b सिंटैक्स:

  for i in 1..=10 {
      println!("{:?}", &a[..=i]);
  }
  

• dotdoteq_in_patterns — एक पैटर्न में a..=b सिंटैक्स:

  match c {
      b'0'..=b'9' => c - b'0',
      b'a'..=b'z' => c - b'a' + 10,
      b'A'..=b'Z' => c - b'A' + 10,
      _ => unreachable!(),
  }
  

  (नोट: a...b सिंटैक्स अभी भी चेतावनियों के बिना स्वीकार किया जाता है)

• inclusive_range — std::ops::{RangeInclusive, RangeInclusiveTo} प्रकार और उनके क्षेत्र:

  let r = 1..=10;
  assert_eq!(r.start, 1);
  assert_eq!(r.end, 10);
  

प्रलेखन

@alercah द्वारा कई दस्तावेज

• किताब: https://github.com/rust-lang/book/pull/1134
• संदर्भ: https://github.com/rust-lang-nursery/reference/pull/215
• जंग-दर-उदाहरण: https://github.com/rust-lang/rust-by-example/pull/1015

परीक्षण

आप में परीक्षण के मामले मिल सकते हैं:

• run-pass/range_inclusive.rs —
  बुनियादी परीक्षण जैसे फॉर-लूप में a..=b का उपयोग करना, एक पुनरावर्तक के रूप में, एक स्लाइस इंडेक्स के रूप में, और ..= ऑपरेटर की प्राथमिकता, और टाइप-चेकिंग व्यवहार।
• libcore/tests/iter.rs —
  एक पुनरावर्तक के रूप में a..=b के व्यवहार के बारे में और परीक्षण; जांचता है कि nth() , min() , max() और last() सही ढंग से काम करती है, और (5..=5).next() पर कॉल करने के बाद सीमा 1..=0 हो जाती है
• liballoc/tests/str.rs , liballoc/tests/btree/map.rs और liballoc/tests/vec.rs —
  जांचता है कि a..=b विभिन्न संग्रह प्रकारों में सही ढंग से काम करता है।
• parse-fail/range_inclusive.rs और ui/impossible_range.rs —
  एक अभिव्यक्ति के रूप में a..= और ..= जैसे बकवास निर्माण सुनिश्चित करता है जिसे संकलित नहीं किया जा सकता है
• parse-fail/range_inclusive_dotdotdot.rs —
  सुनिश्चित करता है कि हम पदावनत अभिव्यक्ति सिंटैक्स a...b और ...b को अस्वीकार करते हैं।
• run-pass/inc-range-pat.rs —
  एक पैटर्न में a..=b और a...b का उपयोग करना सुनिश्चित करता है, दोनों स्वीकृत हैं और समकक्ष हैं।
• compile-fail/range_traits-1.rs और compile-fail/range_traits-6.rs —
  सुनिश्चित करता है कि RangeInclusive और RangeInclusiveTo PartialOrd (अन्य श्रेणियों की तरह) को लागू नहीं करते हैं, और RangeInclusive Copy लागू नहीं करते हैं (नहीं कर सकते कॉपी लागू करें क्योंकि वे इटरेटर हैं)।
• libcore/tests/ops.rs —
  जांचता है कि मैन्युअल रूप से निर्मित RangeInclusive इंस्टेंस को पुनरावृत्त करना काम करता है।

अनसुलझे सवाल

• फॉर-लूप में a..=b का उपयोग करने से a..(b+1) तुलना में बहुत कम प्रदर्शन होता है क्योंकि इसके next() अधिक जटिल और कम अनुकूलक-अनुकूल होने के कारण। यह वर्तमान में #45222 में ट्रैक किया जा रहा है। फ़ोर-लूप के बजाय इटरेटर विधियों का उपयोग करते समय इसे वर्तमान में #48012 द्वारा कम किया जाता है।

  अगर हम अभी तक रस्ट-लैंग/आरएफसीएस#1980 में डिजाइन के लिए प्रतिबद्ध नहीं होना चाहते हैं तो हमें RangeInclusive के क्षेत्रों को अस्थिर रखने की आवश्यकता हो सकती है।

अगर हम अभी तक रस्ट-लैंग/आरएफसीएस#1980 में डिजाइन के लिए प्रतिबद्ध नहीं होना चाहते हैं, तो हमें रेंजइनक्लूसिव के क्षेत्रों को अस्थिर रखने की आवश्यकता हो सकती है।

+1
क्या कुछ विधि-आधारित इंटरफ़ेस के बजाय सीधे श्रेणी फ़ील्ड को बेनकाब करने की कोई आवश्यकता है?

@rfcbot fcp मर्ज

@kennytm के सारांश के अनुसार, मेरा प्रस्ताव है कि हम समावेशी श्रेणी सिंटैक्स ( ..= ) को स्थिर करें।

(उस ने कहा, मुझे ..= के निचले प्रदर्शन को हल्के ढंग से संबंधित लगता है, और मुझे आश्चर्य है कि क्या यह समझ में आता है कि ..= को सीधे लागू नहीं किया गया है Iterator फिलहाल, में इसे कम करने के लिए।)

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

• [x] @ बर्नटसुशी
• [x] @किमुंडी
• [ ] @KodrAus
• [एक्स] @ एलेक्सक्रिचटन
• [x] @ एट्यूरॉन
• [एक्स] @ क्रैमर्टज
• [x] @dtolnay
• [x] @eddyb
• [x] @nikomatsakis
• [एक्स] @ एनआरसी
• [x] @pkfelix
• [x] @sfackler
• [ ] @ नावों के बिना

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

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

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

मुझे आश्चर्य है कि क्या यह समझ में आता है कि ..= इसे कम करने के लिए, समय के लिए सीधे इटरेटर लागू नहीं किया गया है।

ये स्थिर लक्षण RangeInclusive<T> लिए वर्तमान नाइटली में कम से कम कुछ T s के लिए लागू किए गए हैं: Iterator , FusedIterator , ExactSizeIterator , Debug , Clone , Eq , PartialEq , Hash , TrustedLen ।

@SimonSapin मैं भूल गया, क्या हमने पहले से ही संरचना को स्थिर कर दिया है? (दूसरे शब्दों में, क्या यह देखने योग्य है?) मैं मान रहा था कि यह नहीं था।

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

विशेष-मामला क्यों नहीं है जहां end == MAX ? इससे अधिकांश समावेशी श्रेणियां हो सकती हैं जिनमें अनन्य कोड के समान कोड होते हैं, इस अपवाद के साथ कि जो सीधे सीमा पर जाते हैं उनके पास अधिक कोड होता है। क्योंकि end != Max शाखा कभी भी end संशोधित नहीं करेगी, इसे ऑप्टिमाइज़र द्वारा आसानी से इनलाइन किया जा सकता है।

@nikomatsakis नहीं, इस समय

@SimonSapin

नहीं, इस समय संरचनाएं अस्थिर हैं। लेकिन @ kennytm के प्रस्ताव में उन्हें स्थिर करना शामिल है।

समझा; वास्तव में, यही कारण है कि मैंने उल्लेख किया है कि हमें Iterator impl अभी नहीं तो कभी नहीं हटाना होगा। =)

@SimonSapin मुझे नहीं लगता कि हम संरचना को स्थिर किए बिना a..=b अभिव्यक्ति सिंटैक्स को स्थिर कर सकते हैं। हालाँकि हम खेतों को अस्थिर छोड़ सकते हैं, अगर हमें लगता है कि हम इसे बदल सकते हैं।

ठीक है, मेरे कहने का मतलब यह नहीं था कि इन प्रकारों के मूल्यों के निर्माण के लिए सिंटैक्स को स्थिर करते समय हमें प्रकारों को स्थिर नहीं करना चाहिए।

रेंज सिंटैक्स बाइकशेड और स्थिरीकरण से बचने के लिए हुज़ाह! टाडा:

एक टाइम मशीन को देखते हुए, मैं तर्क दूंगा कि रेंज प्रकारों में से कोई भी :Iterator , और वे सिर्फ :IntoIterator । लेकिन जैसा कि अभी है, मुझे लगता है कि रेंज के साथ निरंतरता सबसे अच्छा विकल्प है। हम इस मामले को Chain के साथ "अच्छी तरह से, यह पता चला है कि आंतरिक पुनरावृत्ति कभी-कभी

एक और बात जो अनसुलझी थी, वह भी पुनरावृति से संबंधित है: क्या हम एक बार पुनरावृति करने के बाद रेंजइन्क्लूसिव के किसी विशेष प्रतिनिधित्व के लिए प्रतिबद्ध होना चाहते हैं? अभी यह 1..=0 पर समाप्त होता है , लेकिन अन्य विकल्पों पर भी चर्चा की गई थी । मुझे नहीं पता कि लोगों को इस पर भरोसा करने से रोकने के लिए दस्तावेज़ीकरण पर्याप्त होगा, हालांकि वर्तमान व्यक्ति पुनरावृत्ति सीमा को काफी बेकार बना देता है, जो कम से कम इसे हतोत्साहित करता है।

हम इस मामले को चेन के साथ "कुएं में रख सकते हैं, यह पता चला है कि आंतरिक पुनरावृत्ति कभी-कभी तेज होती है" बाल्टी।

मुझे लगता है कि हमें वास्तव में इसे ठीक करने की आवश्यकता है ताकि एक विशेष श्रेणी से कम प्रदर्शन न हो; होने का कोई मौलिक कारण नहीं है।

इसके होने का कोई _मौलिक_ कारण नहीं है।

यह इस बात पर निर्भर करता है कि हम किन इनवेरिएंट को लागू कर सकते हैं। राज्य के एक अतिरिक्त बिट के साथ पिछले दो फॉर्मूलेशन में, ऐसा कुछ भी लागू नहीं किया गया था कि बिट वास्तव में सेट किया गया था जब हम पुनरावृत्ति कर रहे थे (और वास्तव में यह 100..=0 जैसे अक्षर पर सेट नहीं था), इसलिए लूप निकास की स्थिति जटिल होनी चाहिए, जिसका अर्थ है कि LLVM अब इसे हमारे लिए अनियंत्रित करने के लिए तैयार नहीं है, इसलिए हमें खराब प्रदर्शन मिलता है। ऐसा लगता है कि पूरी तरह से फिक्सिंग का मतलब है कि या तो संरचना को बड़ा बनाना और पब फ़ील्ड नहीं होना, RangeInclusive: !Iterator , या एलएलवीएम को इस प्रकार के लूप को अनुकूलित करने में बेहतर बनाना।

उस ने कहा, मैंने RangeInclusive::next लिखने के कुछ अलग तरीकों की कोशिश की, और ऐसा लगता है कि Option<Ordering> पर मिलान करने के लिए मेरी पिछली स्वयं की पसंद एलएलवीएम को बहुत दुखी कर रही है - बस तुलना करने वाले ऑपरेटरों को इसके बजाय दे रहा है बहुत बेहतर विधानसभा। पीआर अप संपादित करें : https://github.com/rust-lang/rust/pull/48057

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

मैं मूल रूप से इससे सहमत हूं।

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

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

@rfcbot FCP रद्द करें

@withboats और @CodrAus ने अपने बॉक्स चेक नहीं किए हैं।

@cramertj प्रस्ताव रद्द कर दिया गया।

@rfcbot fcp मर्ज

https://internals.rust-lang.org/t/psa-tweaks-to-fcp-process/6775

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

• [एक्स] @ एलेक्सक्रिचटन
• [x] @ एट्यूरॉन
• [एक्स] @ क्रैमर्टज
• [x] @dtolnay
• [x] @eddyb
• [x] @nikomatsakis
• [एक्स] @ एनआरसी
• [x] @pkfelix
• [x] @sfackler
• [ ] @ नावों के बिना

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

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

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

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

@rfcbot fcp चिंता रेंज पैटर्न में एक ऑपरेटर प्राथमिकता मुद्दा है - https://github.com/rust-lang/rust/issues/48501।

( @petrochenkov वाक्यविन्यास <strong i="6">@rfcbot</strong> concern KEYWORD , बिना fcp । हालांकि मुझे लगता है कि केवल टैग की गई टीम सदस्य ही चिंता दर्ज कर सकता है।)

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

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

@दुर्का
मुझे नहीं लगता कि इस स्थिरीकरण के लिए https://github.com/rust-lang/rust/pull/48500 को स्थिर करने की प्रतीक्षा करने की आवश्यकता है
... पैटर्न में अभी भी मौजूद है और इसकी अभी भी पुरानी प्राथमिकता है, इसलिए यदि आपके पास पैटर्न में &BEGIN ... END है (यह बहुत दुर्लभ होना चाहिए मुझे संदेह है) इसे ..= नहीं बदलने का हमेशा एक विकल्प होता है

मुझे लगता है कि हम #48500 को बहुत जल्दी स्थिर कर सकते हैं

व्यक्तिगत रूप से मैं इसे "इंस्टा-स्थिर" w/लैंडिंग ठीक कर दूंगा

inclusive range को स्थिर कर दिया गया है क्योंकि #47813 पुल अनुरोध को मर्ज कर दिया गया है लेकिन यह 1.25 रिलीज में नहीं है, क्यों? हालांकि पुल रिक्वेस्ट को 16 मार्च को मर्ज कर दिया गया था

@mominul मास्टर शाखा में विलय होने के बाद ही एक सुविधा उपलब्ध है, इस प्रकार ..= 1.26 से शुरू होकर उपलब्ध है, न कि 1.25 से।

इस तरह आप उन्हें स्थिर करने के लिए धकेलने से पहले बीटा और रात में उनका परीक्षण कर सकते हैं।

@kennytm और @clarcharr इनपुट के लिए धन्यवाद! कम से कम मेरे लिए रस्ट 1.26 रिलीज निश्चित रूप से उबाऊ नहीं है! :मुस्कुराओ:

मुझे पता है कि इस चर्चा में शामिल होने में बहुत देर हो चुकी है, लेकिन क्यों न .. सिंटैक्स को पूरी तरह से छोड़ दें और इसके बजाय शब्दों का उपयोग करें?

स्कैला में आपके पास 1 to 4 जो [1, 2, 3, 4] , 1 until 4 उत्पन्न करता है जो [1, 2, 3] उत्पन्न करता है, और एक वैकल्पिक by कीवर्ड जो चरण आकार इंगित करता है : 1 to 10 by 2 = [1, 3, 5, 7, 9] ।

यह दोनों इरादे को और अधिक स्पष्ट करते हैं, और "ऑफ-बाय-वन" त्रुटि से बचाते हैं जिसके बारे में हर कोई इतना चिंतित लगता है।

दी, यह सभी मौजूदा कोड को तोड़ देता है, अगर मूल सिंटैक्स समर्थित नहीं रहता है।

@ElectricCoffee रस्ट रेंज में सभी प्रकार का समर्थन करता है, हालांकि केवल संख्याएं नहीं। मुझे लगता है कि हमें इसका समर्थन करने के लिए to और until को कीवर्ड के रूप में पेश करना होगा, और यह एक बहुत बड़ा ब्रेकिंग बदलाव होगा।

यह स्काला में अच्छा काम करता है, लेकिन रस्ट के डिजाइन विकल्प काफी हद तक भिन्न हैं।

@ElectricCoffee हालांकि मुझे इसकी भावना चाहिए, मुझे नहीं लगता कि इसके लिए अतिरिक्त कीवर्ड जोड़ना वांछित है।

मेरा मानना ​​है कि बिल्ट-इन लैंग्वेज कीवर्ड्स को कम से कम रखा जाना चाहिए, क्योंकि वे फंक्शन या वेरिएबल नामों से टकरा सकते हैं।

हालांकि to और until std (जहाँ तक मुझे पता है) में इस्तेमाल किए गए शब्द नहीं हैं, मुझे यकीन है कि वे अन्य क्रेटों में उपयोग किए जाने वाले सामान्य शब्द हैं और परियोजनाओं.

@daboross यह वास्तव में एक उचित बिंदु है जिस पर मैंने विचार नहीं किया, हालांकि कहा जा रहा है, a .. b अर्थ a to b , चाहे a और b वास्तव में हैं।

और हाँ, @timvisee वे शायद हैं।

@ElectricCoffee लेकिन अगर to मतलब ..= और until मतलब .. तो आपको a until b लिखना होगा, न कि a to b a .. b a to b बजाय a .. b । जैसा कि आप देख सकते हैं, यह ऑपरेटरों की तुलना में इन शब्दों का उपयोग करने के लिए "अधिक" सहज नहीं है .. लेकिन until हर जगह लिखना अधिक क्रियात्मक होगा कि .. का उपयोग किया जाता है, क्योंकि यह इससे कहीं अधिक सामान्य है ..= (इसलिए यदि शब्दों का उपयोग किया गया था, तो .. को छोटा शब्द सौंपा जाना चाहिए)।

और आप उस @Boscop के बारे में बिल्कुल सही हैं, हालांकि यह सिर्फ एक उदाहरण था कि शब्दों को कैसे किया जा सकता है।

मेरा मानना ​​है कि मैंने to विशेष के लिए और कुछ भाषाओं में समावेशी के लिए upto ।
यह सब एक विचार के रूप में था।

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

@timvisee एक बस का उपयोग कर सकते a.to(b) और a.until(b) , कोई अतिरिक्त कीवर्ड की जरूरत है (और यह वाक्य रचना भी बहुत कुछ अनाड़ी नहीं है)।

@ hyst329 मैंने इसके बारे में सोचा भी नहीं था। मुझे कहना होगा, मुझे वास्तव में वह विचार पसंद है! आप वाकई सही हैं।

मुझे विश्वास नहीं है कि यह वर्तमान (/ नया) वाक्यविन्यास के लिए उचित पूर्ण प्रतिस्थापन होगा। लेकिन यह एक अच्छा जोड़ होगा।

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

जब तक इसका उपयोग उस संदर्भ में नहीं किया जाता है जहां "ए से बी" का भी उपयोग किया जाता है, यह अस्पष्ट है कि क्या "ए से बी" का अर्थ दक्षिणी ओंटारियो, कनाडा में दिन-प्रतिदिन के भाषण में एक समावेशी या अनन्य श्रेणी है, और "जब तक" संबद्ध है समय के साथ दृढ़ता से पर्याप्त है कि, जब इस शिथिल अर्थ में उपयोग किया जाता है, तो यह स्पष्ट नहीं है कि "घटना" जो "जब तक" के साथ संबद्ध है "जब तक हम एक्स नहीं देखते " या "जब तक हम एक्स को संसाधित नहीं करते"।

@ hyst329 उन्हें विधियों के रूप में रखने से श्रेणियों को संख्या प्रकारों तक सीमित कर दिया जाएगा, हालाँकि। मेरे पास वास्तव में संख्याओं की श्रेणियों के लिए एक वाक्यविन्यास नहीं होगा और दूसरा अन्य चीजों की श्रेणियों के लिए होगा।

मुझे लगता है कि हम रेंज बनाने के लिए प्रस्तावना में एक नया कैच-ऑल फीचर जोड़ सकते हैं, लेकिन यह अभी भी उन चीजों के लिए एक ब्रेकिंग बदलाव पर काम कर रहा है जिनमें वास्तविक to और until तरीके हैं।

मैं स्वीकार करता हूं, मैंने सोचा था कि कीवर्ड का सुझाव एक अप्रैल फूल मजाक था।
..= वाक्य रचना को स्थिर कर दिया गया है।

गुरु, 5 अप्रैल, 2018 को दोपहर 1:53 बजे, डेविड रॉस नोटिफिकेशन @github.com ने लिखा:

@ hyst329 https://github.com/hyst329 उन्हें विधियों के रूप में रखने से सीमित हो जाएगा
हालांकि, संख्या प्रकारों के लिए। मेरे पास वास्तव में इसके लिए एक सिंटैक्स नहीं होगा
अन्य चीजों की श्रेणियों के लिए संख्याओं की श्रेणी और दूसरा।

मुझे लगता है कि हम बनाने की प्रस्तावना में एक नया कैच-ऑल फीचर जोड़ सकते हैं
रेंज, लेकिन यह अभी भी उन चीजों के लिए एक ब्रेकिंग बदलाव पर काम कर रहा है जो है
वास्तविक तक और विधियों तक।

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

हाँ, इस मुद्दे पर हमारी 300+ टिप्पणियाँ हैं, और पहली ही टिप्पणी कहती है:

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

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

मेरा मानना ​​है कि इस मुद्दे से आच्छादित सब कुछ किया जाता है। अगर कुछ और है तो कृपया समस्या के मूल संदेश में चेकलिस्ट को फिर से खोलें और अपडेट करें।