ربما a..b| أو a..b]

أعتقد أن هذا سيفتح الطريق لنوع جديد من الأخطاء غير المتوقعة في المستقبل بسبب خطأ مطبعي بسيط (.. مقابل ...). الأفضل لو كان .... (4 فترات). بهذه الطريقة يكون أقل عرضة للخطأ للعامل البشري ، imo.

أعتقد أن https://github.com/rust-lang/rfcs/pull/1592 و https://github.com/rust-lang/rfcs/pull/1582 معًا يشكلان حالة لاستخدام ..= بناء الجملة بدلا من ذلك. ما لم يكن بإمكان شخص ما التفكير في بناء جملة أفضل من (head..., tail) لتوسيع tuple في مقدمة tuple أكبر.

لقد وجدت هذه المشكلة لأنني واجهت خطأ _off-by-one- dot _ في الكود الخاص بي عندما كنت أنوي استخدام النطاق الحصري.

👎 لبناء جملة ... . أعتقد أن وجود بناء جملة يسهل الخطأ في كتابته يتسبب في حدوث أخطاء متقطعة سيكون بمثابة مسدس قدم.

ومع ذلك ، فإن الوظيفة مفيدة ، لذا يسعدني الحصول عليها بصيغة مختلفة ، على سبيل المثال ..=

هل بناء الجملة لهذا سؤال مفتوح؟ نظرًا لأن ... موجود بالفعل في بيانات المباراة ، فقد افترضت أن السفينة قد أبحرت.

أنا شخصياً أفضل النطاق الشامل ... ، ولكن بما أنه يوجد بالفعل الإصدار الحصري .. ، فإنني أرى احتمال حدوث مشاكل. بعد النظر إلى # 23635 على الرغم من أنني أفضل إهمال .. والسماح فقط ... بالرغم من ذلك.

أستخدم نطاقات شاملة كثيرًا لما يعادل C-like for loops for i in 0..foo.len() حيث يناسب تمامًا ، لذلك أفضل بقاء ذلك (أحتاج إلى هذا ، لأن مكررات Rust "أحادية الأبعاد" وغالبًا محرجًا جدًا لاستخدامه مع المصفوفات ثنائية الأبعاد أو التكرار غير الخطي).

تبدو مشكلة تجاوز النطاقات الشاملة سخيفة ، لكن من الناحية العملية لم أواجه هذه المشكلة مطلقًا ، لأن Rust مزعج للاستخدام مع أي نوع آخر غير usize . إذا لم أقم بالإرسال عند إنشاء النطاق for i in 0..(len as usize) ، فسأضطر إلى استخدام i as usize نصف دزينة من المرات داخل الحلقة على أي حال.

نظرًا لأن بناء الجملة هذا لا يزال محاطًا بالميزات ، آمل ألا تبحر السفينة.

بالنظر إلى أن swift تستخدم ... للشمول و ..< للنطاقات الحصرية ، فإن استخدام ..= للشمول يبدو معقولًا جدًا.

ليس لدي أي إحصاءات مفيدة ، لكني أرغب في استخدام نطاقات شاملة للخروج من الحالة "التجريبية". بينما كنت أتصفح Rust By Example ، وجدت مقتطفًا واحدًا يمكن أن يستفيد من هذا:

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

فوق ؟ 😄

أريد أن أكتب RFC لـ a ..= b بناء جملة ونطاقات معممة. لقد بدأت موضوع مناقشة للحديث عن كيفية تمثيل هذه النطاقات في المكتبة القياسية.

IMHO .. = تبدو غريبة. تبدو طريقة Swift لـ ... و ..

ما زلت أعتقد ... و .. كان جيدًا بما فيه الكفاية. لديك اختلاف في حرف واحد ، لذا فإن ارتكاب الخطأ أصعب من +/- أو x / y أو أي شيء آخر.

نظرًا لأنني أسأت فهم هذا سابقًا (وحذفت تعليقي):

وفقًا لعملية RFC الخاصة بـ Rust ، تمت مراجعة هذا الاقتراح بالفعل ومناقشته والموافقة عليه في طلب سحب RFC 1192 . يتتبع العدد الحالي تنفيذ ما سبق تقريره هناك. غطت المناقشة العديد من النقاط التي أثارها الناس هنا: بناء جملة بديل (بما في ذلك عدم وجود صيغة جديدة) ، والتناقض مع عوامل تشغيل روبي المماثلة ، إلخ.

إذا كنت تشعر بقوة أن الميزة يجب أن تكون مختلفة ، أعتقد أنك بحاجة إلى أن تأخذها من خلال عملية RFC نفسها ، لأن هذه هي الطريقة التي يتم بها إجراء التغييرات على اللغة. لكن هذه القضية ليست المكان المناسب لذلك.

jimblandy ربما ينبغي علينا تعديل nikomatsakis هذا التذكير المهذب والتوجيه في التعليق الأول في Really Big Print. 😇

shepmaster من المحتمل أن يكون هذا أمرًا جيدًا لإضافته إلى نموذج يُستخدم في ملف _all_ مشكلات التتبع.

الترشيح للمناقشة / FCP ممكن

ناقشنا هذا في اجتماع @ rust-lang / lang. كان هناك شعور عام بعدم الرضا عن هذه الميزة - فكرنا في الانتقال إلى الإهمال ، لكننا قررنا تأجيل ذلك في الوقت الحالي. هناك اعتراضان رئيسيان على ... كما هو:

• سهولة الخلط بين .. و ... ؛
• كانaturon يفكر في أنه سيكون من الأفضل أن يكون لديك بنية نطاق أكثر "قدرة كاملة" - يمكن أيضًا استخدام هذا في واجهات برمجة التطبيقات مثل تكرار btree وما إلى ذلك.

تحقيقا لهذه الغاية ، كنا نتساءل عما إذا كان شخص ما على استعداد لدفع RFC إلى الأمام والتي تتيح بناء جملة أكثر عمومية مثل تلك التي تتيح للأشخاص تحديد ما إذا كانت الحدود الدنيا والعليا ستكون شاملة أم حصرية. أعتقد أن aturon سيكون سعيدًا للعمل مع شخص ما في مثل هذا RFC.

أعلم أنني توقفت لفترة من الوقت ، لكنني فتحت مؤخرًا سلسلة مناقشة حول كيفية تمثيل تلك النطاقات ذات الإمكانات الكاملة في libstd (المرتبط أعلاه ) ، لكن لم يعلق أحد:

مع بعض المدخلات على ما سبق ، يسعدني تقديم المساعدة في طلب تقديم طلبات جديد.

لقد فتحت مؤخرًا سلسلة مناقشة حول كيفية تمثيل تلك النطاقات ذات الإمكانات الكاملة في libstd (المرتبط أعلاه) ، لكن لم يعلق أحد:

هذا يعكس إلى حد ما فائدتها.
في حين أن وجود نطاقات تعسفية شاملة وحصرية تبدو فكرة جيدة ، فأنا متأكد من أن كل شيء باستثناء .. وبدرجة أقل بكثير ... لن يتم استخدامها أبدًا.

تضمين التغريدة

أعلم أنني توقفت لفترة من الوقت ، لكنني فتحت موضوع مناقشة حول كيفية تمثيل تلك النطاقات ذات الإمكانات الكاملة في libstd (المرتبط أعلاه) ، لكن لم يعلق أحد:

يبدو هذا تقريبًا مثل النهج الذي كان يدور في ذهننا ، نعم.

تضمين التغريدة

في حين أن وجود نطاقات تعسفية شاملة وحصرية تبدو فكرة جيدة ، فأنا متأكد من أن كل شيء باستثناء .. وبدرجة أقل بكثير ... لن يتم استخدامه أبدًا.

لأكون صادقًا ، أوافق ، لكنني ما زلت أعتقد أنه قد يكون من المفيد اتباع بناء جملة أكثر عمومية. على وجه الخصوص ، أعتقد أن ... هو دون المستوى الأمثل ، ولكن إذا انتقلنا إلى ..= أو شيء أكثر وضوحًا ، فربما لا يضر فعل شيء أكثر عمومية ، حتى لو كان نادرًا تستخدم. بمعنى ، إذا جعلناه منهجيًا ، فلا يبدو من الصعب تعلمه ، ومن المؤكد أنه لن يكون هناك أي لبس حول ما إذا كان .. أو ... يعني "المزيد من الأرقام ".

يبدو هذا تقريبًا مثل النهج الذي كان يدور في ذهننا ، نعم.

أي واحد؟ اقترحت عدة بدائل في رسالتي.

غالبًا ما أرغب في التكرار عبر النطاقات الشاملة وأحب حقًا كتابة 0...x بدلاً من 0..(x + 1) . أفهم أن هذا قد يؤدي إلى حدوث أخطاء فردية ، ولكن ما البدائل المتوفرة لدينا؟

بافتراض أنه يمكن تغيير بناء جملة Rust بحرية دون آثار جانبية ، فإنني أرى فقط بعض الأنماط الواضحة:

أخذها كما هي

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

وهو نمط معروف ويمكن أن يشتمل أيضًا على حجم متدرج. لا أعرف كيف تعمل عملية RFC ، لكنني أعتقد أنه يجب أيضًا مراعاة حجم الخطوات عند الحديث عن النطاقات.

عندما لا يكون حجم الخطوات جزءًا من هذه المناقشة (أو مناقشة مستقبلية) ، يبدو ..= و ..< معقولًا جدًا!

تحديث: أعتقد أن ..= و ..< سيكون حلاً جيدًا حقًا. الحفاظ على الدرجات كمحول أمر منطقي أكثر.

هل يجب أن تتضمن هذه المناقشة نطاقات تنازلية؟ الحل الحالي لعكس النطاق مربك للغاية (ولكن ربما لن يكون كذلك إذا كان لدينا نطاقات شاملة).

على سبيل المثال ، هل يمكنك قراءة وفهم هذا دون التحديق؟

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

تحرير: ومع خط GitHub ، يكون الأمر أكثر إرباكًا حيث يبدو l مثل 1

أعتقد أن خطوة سلبية ستكون كافية.

يمكننا استخدام صيغة Matlab ، a:b و a:step:b .

في 4 تشرين الثاني (نوفمبر) 2016 00:50 ، كتب "Ott" [email protected] :

أعتقد أن خطوة سلبية ستكون كافية.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/rust-lang/rust/issues/28237#issuecomment -258344460 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAC3n3kwnGH6POQb4dGwCwJ8yOGqPSBQks5q6rmDgaJpZM4F4LbW
.

durka إذن ما هو المكافئ لـ .. ، حيث لا يوجد a أو b ؟ فقط : ؟

شيء لم أراه مذكورًا في طلب التعليقات: هل تم وضع أسماء مختلفة للحقول في الاعتبار؟

إذا كانت هناك أنواع مختلفة ، فقد يكون من المفيد وجود أسماء حقول مختلفة عندما يكون لها معاني مختلفة. على سبيل المثال ، "range.start" هو "الحد الأدنى الشامل" في جميع الأنواع. لكن "range.end" يكون في بعض الأحيان شاملاً وحصريًا في بعض الأحيان. إن التمييز بين "النهاية" و (القشور) "الأخير" يجعل ذلك أكثر وضوحًا.

(هذا بالطبع غير ذي صلة إذا تم التخلي عن الأنواع المختلفة لصالح Range> ...)

أعتقد أن النطاق الشامل يجب أن يستمر في تنفيذ std :: collection :: 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 المشكلة في بناء الجملة a: b هي أنها غامضة مع نوع ascription. هل تسأل عن متغير b أم نوع b ؟ من الواضح أننا كمبرمجين جيدين في Rust ، فإننا نستفيد من أنواعنا ، لكن المترجم لا يستطيع استنتاج ذلك.

.. عامل مع تعريفات رياضية (بناءً على تعليق duesee ):

[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 : في Rust ، لا نحتاج إلى نطاقات لا تتضمن البداية. لكن صيغة القوس تكون منطقية فقط عندما يُسمح بها. بالإضافة إلى ذلك ، تم استخدام بنية الأقواس بالفعل.

أعتقد أن ..= هو الخيار الأكثر منطقية للنطاقات الشاملة.
من السهل التمييز بصريًا عن .. ، والذي لا ... . فرصة كتابة ... عندما تعني .. أو العكس بالعكس وعدم الملاحظة أعلى من ..= .
(يمكن مقارنته بكتابة if(a = b) بطريق الخطأ بدلاً من if(a == b) في C ، سواء من حيث الملاحظة المرئية وإمكانية الخطأ).
ومن السهل حفظ ..= لأنه رمزي لمعناه ( i ..= j يعني النطاق i .. j وحيث i = j ).

يبدو أن الشكوى الرئيسية هي أن ... مشابه جدًا لـ .. . لقد لاحظت أنه عند تقديم اقتراحات أخرى تتضمن المزيد من الأحرف ، لا يشكو أحد من عدد الأحرف ، فقط أشياء مثل مطابقة الأقواس واستخدامها في أماكن معينة.
إذن ، ماذا عن .... للنطاقات الشاملة؟ يجب أن يبدو وكأنه نطاق ، وكما قلت لا أحد يبدو أنه يمانع في حل يأخذ طابعًا إضافيًا. من المثير للجدل ما إذا كان أكثر أو أقل من ..= .
for i in 0....10 { println!("just a thought"); }

إذا كان السلوك الافتراضي شاملاً ..! سيتم استخدام عامل التشغيل (تقريبًا كنفي).

المشكلة مع .... أنه سيكون هناك بعض الالتباس إذا كان ... موجودًا بالفعل.

أنا حقًا لا أحب ... أيضًا ، نظرًا لأنه هو بالضبط معكوس روبي .

أفضل خيار حتى الآن هو ..= ما أعتقد.

adelarsq ، .... محل عامل التشغيل ... ، لذا إذا حاولت تنفيذ .. وأضفت . إضافيًا ، فسيكون تجميعًا خطأ زمني ، إذا حاولت تنفيذ .... ونسيت نقطة ، فسيكون ذلك خطأ أيضًا.

نظرًا لأنه في مطابقة النمط ، يتم استخدام ... لمطابقة النطاق الشامل ، لذلك من المنطقي أيضًا استخدام ... لتعبير النطاق الشامل.
بالنسبة إلى النطاق مع الخطوة ، أفضل صيغة Haskell ، على سبيل المثال 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 { }

يشعر بأنه أكثر صحة. قد يكون هذا بسبب خلفيتي C حيث

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

يترجم إلى "طالما أن i أصغر أو يساوي 10 افعل شيئًا". في CI يفضل عدم استخدام == في ظروف الحلقة ، بسبب إمكانية القفز فوق القيمة وينتهي الأمر في حلقة لا نهائية. لا يمكن أن يحدث هذا في Rust ، ولكن ترجمة for i in 1 ..= 10 إلى C قد يوحي بذلك بالضبط.

أخذها أبعد من ذلك ،

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

سيكون واضحا بذاته.

تحرير: هنا مثال عكسي سيئ يهدف إلى توضيح كيف أن استخدام = قد يكون محيرًا. محذوف ، لأنه كان مربكًا أكثر منه بناء.

duesee كيف يكون >=..> غير واضح؟ ألا يجب أن يكون <=..> (<= 10 and> 0)؟
IMO ليس واضحًا بذاته ، إنه غامض وطويل جدًا كمشغل.
(لا ينبغي أن يكون أي عامل أطول من 3 أحرف IMO).
راجع للشغل ، لدينا بالفعل طريقة للتعبير عن اتجاه التكرار العكسي: .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 => :()

• إنه متميز جدًا عن العادي .. ،
• لا يحتوي على دلالة += ..= ،
• إنه متوافق منطقيًا حتى مع ..< لـ Swift. من الممكن أن تتقارب اللغتان!
• والأهم من ذلك أنه من الواضح أنك تحصل على أرقام في النطاق أقل من أو تساوي الرقم العلوي.

pornel : >=..> more species of fish in Rust operators! Hehe :-)

Boscop : لا 10 >= i > 2 . بالنسبة لبقية إجابتك: أنا موافق تمامًا. الجزء الثاني كان بمثابة دافع لإعادة التفكير في ..= مقابل ..<= لعدم إدخال أدوات حظر للإضافات المستقبلية. سوف أقوم بتعديل إجابتي وفقًا لذلك.

يمكن أيضًا الحصول على علامة للتحذير أو حدوث خطأ في ترميز ..

لا أريد أن يظهر .. في أي مكان في قاعدة الكود الخاصة بي

أرغب في إجراء تصويت آخر مقابل ..=

الجانب السلبي لـ ..< و ..<= هو أنهما رمزان صالحان بالفعل (نطاق حصري مفتوح لليمين يتم مقارنته بقيمة أخرى).

تضمين التغريدة

الجانب السلبي لـ .. <و ..

بينما صحيح ، يبدو من غير المحتمل أن تكون هذه مشكلة في الممارسة ، أليس كذلك؟

أفضّل إلى حد كبير ... على الاقتراحات الأخرى هنا .. ولكن إذا اضطررت إلى اختيار صيغة بديلة ، فستكون ..=

تضمين التغريدة

أنا ضد الخيارين ..< و ..<= فقط على أساس أنهما يعقدان بشكل غير متناسب عملية اكتساب نموذج بديهي لقواعد اللغة.

من الناحية الشخصية ، أجدها على الأقل قبيحة وغير أنيقة مثل التوربوفيش.

سأختار .. للحصول على حق حصري و ..= للتضمين كأفضل توازن بين الأناقة المرئية وقواعد النحو التي يسهل فهمها بشكل حدسي ، وتجعل من الصعب الخلط بين الاثنين.

هل ... حقًا غير مميز من .. ؟ لماذا يعجبني كثيرا؟

تضمين التغريدة

يعجبني ... لأنه جذاب من الناحية الجمالية ... لكنني أجادل ضده لأنني أخشى أن يتسبب في أخطاء يصعب ملاحظتها مثل كتابة if (x = 2) { بدلاً من if (x == 2) { في C / C ++. (ومن المؤكد جيدًا ما هو الخطر الذي تحول).

تضمين التغريدة

يتم حل IMO بشكل أفضل عن طريق الفحص أو أعلام الخيارات. لا أرى فائدة كبيرة لخلط الملاحظات في ملف / مشروع واحد.

تفضل أيضًا .... على الخيارات الأخرى ، فإن مضاعفة العرض / التباعد يجب أن يجعل الأمر واضحًا بدرجة كافية خاصة بالنظر إلى أنهما سيتم إحاطةهما على كلا الجانبين برموز ستجعل هذه المساحة السلبية أكثر وضوحًا من العزلة.

تضمين التغريدة

سأذهب مع .. لليمين الحصري و .. = للتضمين كأفضل توازن بين الأناقة المرئية ، وقواعد النحو التي يسهل فهمها بشكل حدسي ، وتجعل من الصعب الخلط بين الاثنين.

إنه يعمل بالنسبة لي. النقطة الشائكة الرئيسية هي ما إذا كنا نريد أيضًا بناء جملة للحالات الأخرى (على سبيل المثال ، <..<= ). أنا شخصياً أشعر أن .. و ..= يغطي مثل 99.5٪ من الحالات. أعتقد أن حالة الاستخدام الرئيسية هي واجهات برمجة التطبيقات مثل drain ، وقد اعتمدنا حاليًا أسلوبًا متميزًا هناك .

cc @ rust-lang / libs

يمكننا ترك الحالات غير الشائعة لإنشاء النطاقات مباشرةً باستخدام
حرفية هيكل.

يوم الأربعاء ، 22 فبراير ، 2017 الساعة 4:50 مساءً ، Niko Matsakis [email protected]
كتب:

ssokolow https://github.com/ssokolow

سأذهب مع .. لليمين الحصري و .. = للشمول كأفضل
التوازن بين الأناقة المرئية ، القواعد النحوية التي يسهل حدسيها
فهم ، وجعل من الصعب الخلط بين الاثنين.

إنه يعمل بالنسبة لي. النقطة الشائكة الرئيسية هي ما إذا كنا نريد أيضًا
بناء الجملة للحالات الأخرى (على سبيل المثال ، <.. <=). أنا شخصياً أشعر أن .. و .. =
يغطي مثل 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
.

durkaandrewtj أفترض أننا سوف نهملها .

..= كمعامل بالمعنى نفسه لـ += .
أقترح استخدام المد ~ ، على سبيل المثال ، 0~9 ، 'A'~'Z' .

ما العملية التي تتوافق مع ..= ؟ - الواضح أن
1-9 == -8 .

يوم الأربعاء 22 فبراير 2017 الساعة 8:04 مساءً ، Junfeng Liu [email protected]
كتب:

.. = يمكن استخدامها كعامل بنفس المعنى + =.
أقترح استخدام ~ ، على سبيل المثال 0 ~ 9 ، "A" ~ "Z".

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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 مساءً ، Junfeng Liu [email protected]
كتب:

durka https://github.com/durka .. = فقط تبدو مثل مهمة
المشغلين ، يجب أن تكون حالة الاستخدام نادرة. ~ هو المد والجزر لا فرعي.

ملء داخلي للنطاق{
fn fill () -> سلسلة {...}
}
ضمني FillAsign لـ RangeAssign{
fn fill (& mut self) {...}
}
(String :: new ("abc") .. String :: new ("f")). fill () // "abcdef"
(String :: new ("abc") .. = String :: new ("f")). fill () // ()

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/rust-lang/rust/issues/28237#issuecomment-281861478 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAC3n39uqbADB1rNtBh3PBTRY2XBXOUNks5rfOD-gaJpZM4F4LbW
.

durkanikomatsakis حسنا، حسنا، آمل أن يتم حل هذا قريبا. الوضع الحالي محرج وسيكون تغيير بناء الجملة أيضًا.

pornel قد يؤدي إهمال ... في match إلى كسر التوافق ، لذا فهو ليس حلاً جيدًا. ما زلت أجد ... هو الأكثر ملاءمة (على الرغم من أنه معكوس دقيق لـ Ruby ، ​​لكن لم تتم مناقشة مشكلة مماثلة بواسطة Rubyists).

@ hyst329 ولكن يمكن أن يكون ... أكثر عرضة للأخطاء ، نظرًا لأن فقدان أو إضافة . سيعطي معنى جديدًا

الاستنكار لا يكسر الأشياء. سيتعين دعم البنية القديمة للبرامج الحالية إلى الأبد ، ولكن يمكن توجيه المستخدمين نحو البنية الجديدة عبر التوثيق و rustfmt.

ولكن يمكن توجيه المستخدمين نحو بناء الجملة الجديد عبر التوثيق و rustfmt.

أوصي بشدة بعدم استخدام rustfmt لذلك. سيؤدي إلى تفاقم صفات مسدس القدم لـ ... عند استخدامه في وضع "تطبيق التغييرات تلقائيًا" لأنه يمكن أن يترجم الأخطاء الإملائية بصمت إلى أشياء تبدو أكثر فائدة. (مما يسهل إغفالها عند الفحص اللاحق).

تحذير المترجم في سياق "الرجاء التحقق مما قصدته واستخدام إما .. أو ..= " والذي لا يمكن إصلاحه تلقائيًا سيكون أكثر انسجامًا مع الجهود الحالية لتقليل فرصة لخطأ بشري.

يرجى ملاحظة أنني كنت أتحدث في سياق أنماط ... الموجودة ، حيث لا يوجد مسدس قدم. يقع Rust حاليًا في وضع خالي من المسدسات حيث تسمح الأنماط فقط بـ ... وتسمح التعبيرات فقط .. ، لذلك كلاهما في مأمن من الأخطاء المطبعية.

بالطبع لا أوصي بتحويل ... في التعبيرات إلى ..= ، لأن هذا بالطبع سيجعل الخطأ المطبعي دائمًا.

آه. لقد نسيت ذلك. شكرا لتذكيري.

adelarsq في الواقع ، يمكن 'a'..'z' أو 128u8..255u8 بسهولة في cargo-clippy كتحذيرات ، على سبيل المثال. وأيضًا ، يختلف عرض .. و ... بشكل واضح (عند استخدام خط أحادي المسافة ، بالطبع ؛ عدم استخدامه عادة ما يكون فكرة سيئة لكتابة التعليمات البرمجية المصدر بشكل عام - وليس فقط Rust) .

يمكننا أن نجعل بناء الجملة هو … (علامات حذف أفقية أحادية الشفرة) بدلاً من ... بهذه الطريقة على الأقل لن يكتبها أحد عن طريق الصدفة.

تحرير: أوه لا أحد كان يتعامل مع هذا الاقتراح بجدية: البكاء: آسف على الضوضاء.

لا أعرف ، آخر مرة تحققت فيها من محرر مستندات Google يتحول تلقائيًا ... إلى علامة حذف. لاعب رئيسي في صناعة تحرير النصوص.

أيضا، وليس كل شخص لديه مفتاح يؤلف لكتابة مريح إنشاء. . عندما لا تريد …

في Windows يمكنني كتابة علامات الحذف باستخدام Alt + 0133 مع اللوحة الرقمية! …

وتوجد آليات مماثلة قائمة على نقاط التشفير في طبقات مختلفة من المكدس على أجهزة الكمبيوتر المكتبية المستندة إلى X11 (أتذكر أن GTK + ومكدس الإدخال X11 لهما حلولهما المستقلة) ولكن من المتاعب تذكر نقاط التشفير حسب الرقم.

يؤلف هو الحل بديهية جدا.

تسلسل Windows Alt الوحيد الذي أتذكره هو Alt + 219 من جميع قوائم ملفات DOS Batch التي قمت بإنشائها عندما كنت طفلاً.

الصيغة الحالية موجودة منذ وقت طويل بالفعل ، دعنا نثبتها بالفعل ونوقف هذا التساقط اللانهائي للدراجات.

الحفاظ على بناء الجملة الحالي هو أسوأ ما يمكن أن نفعله لأنه يحتوي على العديد من العيوب الحقيقية . هذا ليس مجرد تزييف للدراجات - يجب أن يتم بشكل صحيح. تخطي كامل الموضوع ، حصل بناء الجملة ..= على أكبر قدر من القبول حتى الآن ...

أشعر قليلاً وكأنه يضرب حصانًا ميتًا في هذه المرحلة ، ولكن عندما تفكر في الأمر ... الفرق بين .. و ... هو حرفياً نسخة واحدة من أصغر شخصية ممكنة يمكن أن تكتب أو تقرأ ، مختلطة مع مجموعة من الأحرف المتطابقة ، ولديها القدرة على إنشاء فئة خطأ شائعة للغاية وغالبًا ما يصعب العثور عليها (أخطاء متقطعة) في الحالات التي لا يمكن تمييزها تمامًا للإنسان والآلة.

أو يمكننا فعل أي بناء جملة آخر في العالم حرفيًا.

من ناحية ، أقدر هذا القلق .. من ناحية أخرى ، فإن بناء جملة مطابقة النمط الحالي ... شامل بالفعل ، مما يجعله متسقًا تمامًا مع البنية المستخدمة بالفعل في مكان آخر في Rust.

وليس لدي شخصيًا أي مشاكل في التعرف على الاختلاف ، على الرغم من أنني أدرك أن الأشخاص الذين يعانون من مشاكل في الرؤية ، أو مع شاشة 4K وخط 10pt ، قد يفعلون ذلك.

ولكن يبدو أن الإجماع على ..= وأعتقد أنني بخير مع ذلك أيضًا.

FWIW ، لقد مررت بهذا الموقف حيث كتبت عن طريق الخطأ ... عندما كنت أعني .. ثم لم ألاحظ ذلك لفترة من الوقت ، ولكن بعد فترة تساءلت عن سبب تصرف برنامجي بشكل غريب.
لذا ، نعم ، يجب أن يكون هناك فرق أكثر وضوحًا ، و ..= هو الأكثر منطقية.

الترشيح لمناقشة @ rust-lang / lang. أعتقد أننا يجب أن نتبنى ..= ونطلق عليه يوميًا. هل نحن بحاجة إلى RFC معدلة؟ افعل ذلك؟ هل يتضمن ذلك إهمال بناء جملة ... في الأنماط؟ (أفترض ذلك).

أنا أؤيد بشدة عدم استخدام ... للنطاقات. لا أعرف ما إذا كان قد تم ذكره في سلسلة المحادثات هذه أم في سلسلة محادثات RFC بالفعل ، ولكن بالإضافة إلى أن ... يشبه بشكل غير معقول مظهر .. ، فقد نرغب أيضًا في استخدام ... في المستقبل للأدوية المتغيرة ، والتي تعتبر أكثر أهمية من النطاقات الشاملة IMO.

..= واضحًا ، والقبح النسبي له ما يبرره من خلال كونه أقل شيوعًا من .. .

هل يتضمن ذلك إهمال ... بناء الجملة الموجود في الأنماط؟ (أفترض ذلك).

هذا يبدو وكأنه فكرة جيدة. حذر من ... وادعم الأنماط .. و ..= إذا استطعنا.

أنا حذر عمومًا من تقديم التحذيرات التي قد تؤثر على الكثير من الأشخاص دون أن يكون لدي أيضًا أداة آلية لتحديث بناء الجملة ، ولكن تغيير بسيط بشكل خاص هو ... إلى ..= . يمكننا أيضًا إيقاف العمل ولكن تأجيله لجعله تحذيرًا حتى نحصل على مثل هذه الأداة. ماذا يعتقد الجميع؟

أنا أؤيد بشدة استخدام ... لأنه بناء جملة "عادي" أكثر ؛ لا أعرف أي لغة تستخدم ..= ، لكن الكثير منها يستخدم .. و ... .

إذا كانت المشاعر ضد ..= قوية ، فإنني أفضل عدم استخدام بنية نطاق شاملة (بدلاً من اختيار طريقة (a..b).inclusive() ، والتي تبدو موجزة بدرجة كافية بالنسبة لي) لتجنب المشكلة المرئية ومرة ​​أخرى مجانًا حتى ... للأدوية المتغيرة.

تحرير: إحدى الحجج الجيدة ضد (a..b).inclusive() هي أنه لا يزال لدينا ... في match ولا توجد صيغة جديدة لاستبدالها ، للأسف. :خجول:

steveklabnik نعتذر إذا تم ذكر ذلك بالفعل في مكان ما في هذا الموضوع (الطويل جدًا) ، ولكن: ما هي اللغات الأخرى التي تستخدم كلاً من .. و ... للنطاقات الحصرية والشاملة ، على التوالي؟

يمتلك Rust تاريخًا في تبني ميزات مفيدة وبناء جملة من لغات أخرى ، ولكن بشكل انتقائي ، ورفض الأشياء أو تكييفها عند الاقتضاء.

يستخدم joshtriplett Ruby كلاهما ، ولكن مع معاني .. شامل ، ... حصري). لا أعتقد أنها كانت فكرة جيدة في روبي ، ويبدو أنه من المحتمل أن يكون الأمر محيرًا بالنسبة لنا ، ولكن بالعكس.

joshtriplett أكثر ما ..= .

بصراحة ، أفضل بناء جملة مستقر وشامل على أي شيء آخر ، وأدرك أن كره الشديد لـ ..= هو شيء شخصي ، قد يختلف عليه الأشخاص العقلاء.

steveklabnik Swift يستخدم ..< ، على ما أعتقد ، أليس كذلك؟ الذي يبدو مشابهًا لـ ..= ولكنه أسوأ ، من حيث أنه يحسن الحالة الخطأ (imo). =)

يستخدم Swift .. <حصريًا و ... شاملًا (شروطها
"نصف مفتوح" و "مغلق").

ما زلت أحب .. <(مع .. كاختصار) و .. =.

لكن هناك سؤال مفتوح آخر (ربما ليس ضمن اختصاص مشكلة التتبع هذه) وهو ما إذا كنا "فقط" نعتمد بناء جملة للنطاقات المغلقة ، أو أيضًا بناء جملة (بناء الجملة؟) للنطاقات مع النقطة الأولى مفتوحة ، مثل المبتدئ> ..> و > .. =.

يوم الخميس ، 16 مارس 2017 الساعة 2:19 مساءً ، Niko Matsakis [email protected]
كتب:

steveklabnik https://github.com/steveklabnik يستخدم Swift .. <، على ما أعتقد ،
حق؟ وهو ما يبدو مشابهًا لـ .. = ولكنه أسوأ ، من حيث أنه يحسن من أجله
(IMO) الحالة الخطأ. =)

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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) {

}

لم أشعر أبدًا أن التناسق مع التطابق هو حجة مقنعة. أعتقد أننا قررنا إضافة أنماط .. حصرية ، لكني لا أحب تلك أيضًا - قيمة في النمط الآن لا يقابلها النمط! تختلف مطابقة النطاق اختلافًا جوهريًا عن التكرار عبر نطاق ، فلا داعي لأن تكون متماثلة. لدي تفضيل معتدل لعدم السماح بأنماط .. إذا كان لا يزال خيارًا ، لكنني أعتقد أنه ليس كذلك؟

أشعر بالجوانب السلبية مع ..= و ... كلاهما مهمان - ..= غريب تمامًا ، لكن ... يزيد من احتمالية حدوث خطأ واحد.

من الأفضل أن يكون لديك عامل ذو مظهر غريب من مثل هذه الإمكانية التي لا تنتهي للأخطاء (كل لغة تقدم عوامل تشغيل لا يمتلكها الآخرون ، على سبيل المثال ..< في Swift ، وجميع العمليات في F # و Scala). سيتعين على الناس قراءة كتاب Rust على أي حال.
بالنظر إلى أن الكثير من الناس يأتون إلى Rust من Ruby ، ​​فلا ينبغي أن نعكس الأمر مقارنةً بـ Ruby. (بالإضافة إلى الحجة القائلة بأن ... يزيد من احتمالية الخروج بمقدار خطأ واحد.)
كيف يمكنك قبول ..< في Swift لكن لا تقبل ..= في Rust؟ ..= ليس بهذا الغريب.

لا يزال توسيع بناء جملة النطاق في الأنماط سؤالًا مفتوحًا وكذلك AFAIK.
لسبب واحد ، لا يمكننا القيام بذلك بشكل كامل ، لأن Enum::Variant(..) موجود بالفعل
صالح وتغييره ليعني Enum::Variant(RangeFull) سيتم كسره.

في الخميس ، 16 مارس 2017 الساعة 3:07 مساءً ، كتب Boscop [email protected] :

من الأفضل أن يكون لديك عامل تشغيل غريب المظهر (كل لغة تقدم
عوامل التشغيل التي لا يمتلكها الآخرون ، على سبيل المثال .. <في Swift ، كل العمليات في F #
وسكالا). سيتعين على الناس قراءة كتاب Rust على أي حال.
بالنظر إلى أن الكثير من الناس يأتون إلى روست من روبي ، نحن
لا ينبغي أن يكون عكسها مقارنة مع روبي. (بالإضافة إلى الحجة
أن ... يزيد من احتمالية الخروج بمقدار خطأ واحد.)
كيف تقبل .. في سويفت ولكن لا تقبل .. = في الصدأ؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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 . في الواقع ، إنها النوع الوحيد من النطاق الذي ندعمه كنماذج اليوم.

withoutboats نعم ولكن قلت "عدم وجود بنية نطاق شاملة لن يسمح باستخدامها في المباراة". يوجد الآن بناء جملة لكن حجتي كانت ضد .inclusive() لأنه لا يمكن استخدامها في المباراة إلا إذا كان لدينا مستخرجون مثل Scala. والمقصود من هذه المشكلة هو أن بناء جملة النطاق الشامل لا ينبغي أن يكون حالة خاصة تعمل فقط في المطابقة ولتحديد الصيغة التي يجب أن تكون بدلاً من الصيغة الحالية.

شامل: for i in 1..10! { }

بصفتي شخصًا يعمل أكثر من 15 عامًا مع Java / C / C ++ ، أجد أن .. مقابل ... مربك جدًا وقد يتسبب في أخطاء بمجرد كتابة الأخطاء. كما أن العلاقة مع روبي تجعل هذا الأمر أكثر إرباكًا. هذا هو السبب في أن ..= أو أي بديل آخر هو الأفضل.

رمي "قبعتي" في الحلبة:

for i in 1..10^

القبعة / علامة الإقحام التي ترمز إلى أن القيمة الصحيحة تسير على طول الطريق _up_.

leebenson شخصيًا ، أعتقد أنه سيكون من الأفضل لو كان في المنتصف ، وليس من الخارج.

for i in 1..^10

@ retep998 اعتبرت أنه بعد أن

@ retep998 يعجبني اقتراحك بـ ..^ أفضل بكثير من ..= ؛ يبدو أكثر استحضارًا لمعناه ، ويتجنب الظهور كمتغير غريب لمشغل التعيين المعزز (مثل += و *= ). ومع ذلك ، فإن أيًا منهما سيكون أفضل بكثير من ... .

لا أستطيع أن أتخلف عن ..^ .

على المستوى الشخصي ، أجده قبيحًا جدًا (جزئيًا لأن .. منفصل رأسياً عن ^ في العديد من الخطوط).

بصفتي شابًا UI / UX ، أعتقد أنه مثال على كونك ذكيًا جدًا من أجل مصلحتك.

إذا أتيت من لغة أخرى ورأيت ..^ ، فقد لا أتعرف عليها على أنها نطاق (لكل ما أعرفه ، قد يكون 5..^15 اختزالًا جزئيًا غريبًا مقابل 15! - 4! ) لأن البشر يفكرون في السياقات وأن الارتباط الوحيد الذي تمتلكه هذه الشخصية في سياق البرمجة السائد هو الأس.

(إذا لم نفكر في السياقات ، فقد يعني ... شيئًا مثل "يتم إدراج رد الاتصال هنا" أو "إرسال حدث" عن طريق القياس على "المحتوى المحذوف" - مثل المعنى في الحوار في كتابة النثر ، فقط إظهار المثال الأكثر إلحاحًا. إن إعطائه معنى "يصل إلى أعلى" عبر تشابهه مع سهم يشبه القيام بالخدع السحرية عبر خفة اليد ، بقدر ما يتفاعل مع توقعات الوافد الجديد.)

على النقيض من ذلك ، فإن = له سابقة للإشارة إلى كل من إجراء الإسناد ومفهوم المساواة وليس هناك "صيغة أسية غريبة" - مثل الاعتقاد الخاطئ بـ ..= لأن أقرب ما يمكنك الوصول إليه " التخصيص + المساواة "التي لم يتم التعامل معها بالفعل من قبل عامل التخصيص هي" شيء له علاقة بسلسلة من الأرقام تنتهي على الجانب الأيمن "... وهو تعريف غامض ولكنه مناسب لما يفعله بناء جملة النطاق.

أشعر بالقلق أيضًا من أنه حتى لو أدركت أن ..^ كان عبارة عن بناء جملة من استخدامه في السياق ، فلن يكون لدي أي فكرة بديهية عما إذا كان شاملاً أو حصريًا في البداية ، لأنه لا يوجد معنى لـ ^ في السياق ذي الصلة ، باستثناء احتمال أن يكون 2..^8 اختصارًا لنطاق مفتوح يبدأ من اثنين ويتدرج من خلال اتخاذ الخطوة السابقة إلى قوة 8. (على سبيل المثال ، 2..Inf^8 بدلاً من 2..+8 اختصارًا لـ "التكرار من 2 إلى اللانهاية بخطوات 8".)

يتم أيضًا تجنب هذه المشكلة من خلال ..= لأن الناس معتادون على التفكير من حيث < (حصري) مقابل <= (شامل) عند كتابة while الحلقات وحلقات C-style for .

ssokolow التحليل

أنا شخصياً يمكنني أن أتخلف إما ..= أو ..^ . إن ترميز أي منهما يبدو منطقيًا بالنسبة لي - أي "يصل إلى ويساوي" أو ببساطة "يصل إلى" ، على التوالي. كلاهما يعني نفس الشيء ، في رأيي.

سيكون من الصعب التوصل إلى شيء يرضي الجميع ، لأننا جميعًا نأتي بالتاريخ من اللغات الأخرى ومعها ، الرموز / التحيز الملوث. في البداية أضفت علامة ^ _after_ الرقم ، على سبيل المثال ، لأن الإدخال من قبل كان يشعرك بأنه يمثل "خطوة" أو أسًا ، بينما تركت اللاحقة النطاق غير ملوث ، وشعورًا أكثر نقاءً بطريقة ما. لكن هذا أنا فقط.

على أي حال ، أفضل تدوينًا مختزلاً في شكل ما مقابل استدعاء دالة والذي يتضمن ضمنيًا + 1s على val الأيمن. أنا أتفق مع التعليقات السابقة على أن هذا بناء جملة شائع جدًا بحيث لا يمكن تفويض شيء يشبه استدعاء وظيفة. حتى أنني لا أمانع ... ، لكن منحت ، ربما يكون الخطأ = / == في الملابس الجديدة ولا بد أن يطلق النار على شخص ما في قدمه ...

يبدو أن الكثير من الناس يكرهون بشدة .. = لم يقل أحد شيئًا سلبيًا
حول .... تم فقط تجاهله بهدوء (باستثناء القليل من الإبهام)
اعتقدت أنني سأطرحه مرة أخرى وأطلب من الناس النظر فيه وإعطاء
سبب عدم استخدامه إذا كانوا ضده.

أكره حتى أن أذكرها لأنها مجرد ضوضاء ، ولكن ماذا عنها.:
(نقطة كولون) لتضمين؟ إنها 3 نقاط ولكن شخصيتان ، وأعتقد أن
الشكل يجعلها متميزة عن ..

يوم السبت 18 مارس 2017 الساعة 11:50 صباحًا ، Lee Benson [email protected]
كتب:

ssokolow https://github.com/ssokolow التحليل الشرعي .

أنا شخصياً أستطيع أن أتخلف إما .. = أو .. ^. ترميز إما
يبدو منطقيًا بالنسبة لي - أي "يصل إلى ويساوي" أو ببساطة "يصل إلى" ،
على التوالى. كلاهما يعني نفس الشيء ، في رأيي.

سيكون من الصعب التوصل إلى شيء يرضي الجميع ،
لأننا جميعًا نحضر التاريخ من لغات أخرى ومعها ملوث
الترميز / التحيز. في البداية أضفت علامة ^ بعد الرقم ، لـ
على سبيل المثال ، لأن الإدخال من قبل كان يشعر بأنه يمثل "خطوة"
أو الأس ، بينما تركت اللاحقة النطاق غير ملوث ، وأكثر نقاءً إلى حد ما
شعور. لكن هذا أنا فقط.

على أي حال ، أفضل تدوينًا مختزلاً في شكل ما مقابل أ
استدعاء الوظيفة الذي يشير ضمنيًا إلى + 1s في اليد اليمنى. أنا أتفق مع في وقت سابق
التعليقات بأن هذا بناء جملة شائع جدًا بحيث لا يمكن تفويض شيء ما
يبدو وكأنه مكالمة وظيفية. حتى أنني لا أمانع ... ، لكنني موافق ، إنه كذلك
ربما يكون الخطأ = / == في الملابس الجديدة ولا بد أن يطلق النار على شخص ما في
قدم...

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/rust-lang/rust/issues/28237#issuecomment-287566556 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AIhJ6jWgPwndKaQvVjULlV_OoC6WDO0Cks5rnCeLgaJpZM4F4LbW
.

أوه ، هل هذا لا يزال في مرحلة الزفاف؟ 😆

إعادة القراءة ، أعتقد أنني أتفق مع nikomatsakis لجعلها ..= وأطلق عليها اسمًا يوميًا. التشابه بين .. مقابل ... دقيق للغاية ، وأنا أفضل أن أرى الرمز المميز ... يتم استخدامه بدون غموض للأدوية المتغيرة (https://github.com/ rust-lang / rfcs / pull / 1935) ، حيث تحقق غرضًا مميزًا للغاية يجب أن يؤدي إلى ارتباك أقل بين الاثنين.

لست متأكدًا مما إذا كانت الرغبة في بناء جملة أكثر عمومية لجميع المتغيرات نصف المفتوحة لا تزال موجودة ، لكنني أعتقد أنه لا يستحق الجهد المبذول لتوفير بناء جملة لغوي خارج .. و ..= .

أكره حتى أن أذكرها لأنها مجرد ضوضاء أكثر ، ولكن ماذا عن.: (نقطة القولون) للتضمين؟

أعتقد أن ssokolow قدم بعض النقاط الرائعة فيما يتعلق بإعادة: واجهة المستخدم / كونك ذكيًا. كنت أزعم أن تبديل اتجاه النقطة الثالثة من أجل خداع عينيك لرؤية شيء آخر من المحتمل أن يكون في هذه الفئة.

أنا شخصياً لديّ اعتراض _صفر_ على وجود نقطة ثالثة ، بخلاف معرفة أنه لا بد أن يؤدي إلى تعثر بعض الأشخاص في النهاية. ولكن من السهل شرح ذلك أيضًا ، لذا لست متأكدًا من أن المسؤولية تقع على عاتق اللغة لتصميم حلول ذكية. عبارة عن نقطتين حصريتين ؛ 3 نقاط شاملة "التي يصعب فهمها / تصحيحها حقًا؟

على أي حال - من يتخذ القرار النهائي ، وما هي الخطوة التالية لإغلاق هذا القرار؟ 18 شهرًا من مناقشة الشخصية الثالثة ربما _ is_ bikeshedding في هذه المرحلة 😄

متفق عليه ، ^ يجعلها تبدو كخطوة.
IMO لا يمثل عدم الاتساق مع عوامل التشغيل الأخرى op= مشكلة لأنه لا توجد طريقة يمكننا من خلالها الحصول على a ..= b بمعنى a = a .. b ، نظرًا لأن .. هو ليس عاملًا ولكن سكرًا نحويًا لإنشاء نطاق (وليس لدينا مخطط التحميل الزائد العام للعمليات حيث يحصل أي عملية تلقائيًا على شكل op= و .. ).
أنا لا أقول أن ..= واضح دون النظر إلى المستند. ولكن بمجرد أن ينظر الأشخاص إلى المستند ، يصبح حفظه أسهل ، وسيتعين عليهم إلقاء نظرة على المستند على أي حال.

بالنظر إلى ترشيح nikomatsakis ، أعتقد أننا

أشعر بالقلق أيضًا من أنه ، حتى لو أدركت أن ..^ كان عبارة عن بناء جملة من استخدامه في السياق ، فلن يكون لدي أي فكرة بديهية عما إذا كان شاملاً أو حصريًا في البداية

متفق. في الواقع ، لقد رأيت بالفعل هذه الصيغة في Perl 6 حيث تعني حصرية ، عكس الاقتراح هنا.

solson هذه حجة مقنعة للغاية ضدها.

يبدو أن لغة Perl تمتلك تركيبًا عامًا بالكامل ، مع .. بمعنى شامل (على كليهما
على الجانبين) و ^ على كلا الجانبين يجعل هذا الحد حصريًا.

السبت، 18 مارس 2017 في 06:51، جوش تريبليت [email protected]
كتب:

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 ، فشلنا في التوصل إلى توافق في الآراء. withoutboats على وجه الخصوص لديه بعض التحفظات الشديدة التي نأمل أن يتمكنوا من بثها لأنفسهم.

بعض النقاط الرئيسية التي ناقشناها:

• إذا كان لدينا نطاق شامل في التعبيرات والأنماط ، فيجب أن يكون هو نفسه
  
  
  
  • على سبيل المثال ، إذا اعتمدنا x ..= y ، فهذا يعني إهمال بنية النمط الحالية x...y .
  
  
• من الخيارات المغرية ألا تفعل شيئًا وأن تكتب فقط (x..y).inclusive() أو شيئًا من هذا القبيل. ومع ذلك ، لن يعمل ذلك في الأنماط (والتي من المفترض أن تظل مثل x...y ). هذا يثير بعض الأسئلة من تلقاء نفسها:
  
  
  
  • هل ما زلنا نريد أنماط نطاق حصرية ؟ على سبيل المثال ، match 3 { 1..3 => false, .. }
    
    
    
    
    
    • إذا كان الأمر كذلك ، فلدينا نفس الارتباك المحتمل!
    
    
    
  
  
  • withoutboats يبدو أنه يعتقد أننا ربما لا نريد مثل هذه الأنماط. كنت أنا و @ joshtriplett مشكوكين في هذا ؛ أعتقد أن كلانا كان لديه رأي مفاده أنهما من النوع الذي يبدو غير ذي صلة حتى تريدهما ، ومن ثم يشعران أنهما ضروريان للغاية . =)
  
  
• هناك مشكلة أخرى تتعلق بأنماط النطاق الحصرية وهي أن التفاعل ضعيف مع أنماط الشرائح (غير المستقرة أيضًا) (راجع https://github.com/rust-lang/rust/issues/23121 للحصول على التفاصيل).

أعتقد أن أحد الأشياء التي خرجت من هذه المناقشة هو أنه سيكون من الجيد اتخاذ قرار بشأن جميع العوامل المتضاربة في وقت واحد . بعبارة أخرى ، لاتخاذ قرار يستقر:

• ماذا تفعل حيال تعبيرات النطاق الحصرية؟
• هل يتعين علينا إهمال / تغيير أنماط النطاق الحصري الحالية؟
• ماذا تفعل بشأن أنماط النطاق الشامل ؟
• ماذا تفعل حيال أنماط الشرائح ؟

قبل أن أبدأ هذه الكتابة ، أود أن أقول إنني شعرت بعدم اليقين الشديد في أنه في كل لحظة من المحادثة كنا نتحدث جميعًا عن نفس المفهوم. على سبيل المثال ، يقول نيكو أن "أنماط النطاق الحصرية تبدو غير ملائمة حتى تريدها" ، لكنني اعتقدت أن نيكو وجوش كانا يتحدثان عن تعبيرات النطاق الشامل في ذلك الوقت.

(وأعتقد في الجزء الأخير من منشور نيكو ، أن الرمز النقطي الأول الذي يقرأ حاليًا "تعبيرات النطاق الحصرية" يجب أن يقول "تعبيرات النطاق الشامل".)

TL ؛ DR رأيي

حول تعبيرات النطاق:

• يجب ألا نقدم أي صيغة لتعبيرات النطاق الشاملة - لا ... ولا ..= .
• يجب أن نضيف إلى المقدمة دالة تأخذ قيمة نطاق حصرية وتعيد قيمة نطاق شاملة. لذا ستكتب inclusive(0..10) (يمكن أن يكون الاسم مضمّنًا بالدراجات).

حول أنماط النطاق:

• يجب ألا نقدم أنماط نطاق حصرية ، أو بأي طريقة لإنشاء واحدة.

بعبارة أخرى ، التغيير المادي الوحيد الذي يجب أن نقوم به هو تغيير libs: إضافة وظيفة إلى المقدمة.

تعابير المدى

من الأمور الأساسية في حجتي حقيقة أن التكرار من خلال قيمة النطاق الشامل هو حاجة غير شائعة. أعتقد أن هذا تؤكده حقيقة أنه على الرغم من قبول RFC قبل 18 شهرًا ، ما زلنا لم نقم بتثبيت هذه الميزة - ليس بسبب مشكلات التنفيذ ولكن لأننا لسنا سعداء بالمقايضة.

أعتقد أن هناك حاجة إلى تعبيرات النطاق الشامل في كثير من الأحيان بما يكفي لدعم طريقة مباشرة لإنشائها ، ولكن ليس في كثير من الأحيان بما يكفي للتغلب على أي من الجوانب السلبية للصيغ النحوية التي ناقشناها حتى الآن.

على وجه الخصوص ، الجانب السلبي الذي يشاركه كل حل نحوي هو أنه لا يوجد أي منها يقوم بالتوثيق الذاتي حقًا. من غير الواضح نسبيًا أن 0...10 أو 0..=10 هو تعبير نطاق شامل . نظرًا لأنه سيتم مواجهتها بشكل غير متكرر نسبيًا ، فسيكون هذا حجر عثرة للمستخدمين الذين يواجهونها لأول مرة.

أي ، إذا لاحظ المستخدم أنه لا يتعامل مع نطاق "عادي" .. . بالطبع ، هذه هي المشكلة الكبرى مع ... ، لكن ..= لا يقضي على المشكلة = (أو ^ أو : أو أي شيء آخر). ليس سهلاً مثل . الإضافي ، لكنني لست مقتنعًا أنه ملحوظ بدرجة كافية.

أعتقد بالفعل أن هناك مقايضة بين "الملحوظة مقابل الوضوح" بين ... و ..= . أعتقد أن ما يعنيه ... أكثر وضوحًا (ما لم تكن قادمًا من Ruby ، ​​حيث يكون للصيغتين معنى معاكس) من ..= ، لكنه بالتأكيد أقل وضوحًا .

لكنني أعتقد أن دالة تمهيدية مثل inclusive(0..10) هي أكثر وضوحًا ولفترة أكبر من أي بناء جملة ناقشناه. نعم ، يجب كتابة المزيد من الأحرف ، لكن الجانب السلبي لهذه السمة يتعلق بتكرار الاستخدام.

كما أنه يتجنب أي من مشكلات التحليل والرمز المميز ، ويساعد المستخدمين في مشكلة أسبقية الطريقة (المزعجة للغاية) مقابل الطريقة التي تتطلب منهم كتابة (0..10).filter وهكذا.

أنماط المدى

السبب الرئيسي في اعتقادي ألا نضيف .. هو أنه يُدخل الغموض حول أنماط الشرائح ، وهو ما أعتقد أنه مفيد. أود حل هذه المشكلة بعدم الاضطرار إلى حلها.

السبب الثاني هو أنني أعتقد أنهم أسلوب سيء للغاية (أعرف أن الآخرين يختلفون). فمثلا:

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

أعتقد أن هذا محير ، لأن 10 لا يتطابق مع النمط الذي يحتوي عليه. ذكر نيكو أن هذا لا يختلف حقًا عن تعبيرات النطاق الحصرية التي لا تنتج 10 ، لكنني أعتقد أن الاختلاف الكبير هو أن لدينا قدرًا كبيرًا من سابقة تاريخية على غرار Dijsktra (وحالة الاستخدام) لدعم الحصري نطاقات. عند الدخول في Rust ، توقعت أن تكون النطاقات التكرارية والتقطيع حصرية ، لكن لم يكن لدي هذا التوقع للأنماط.

كما أن لديها مشكلة "كل على حدة" التي بها .. / ... في التعبيرات.

أعلم أن نيكو قد ذكر أنه يود أن يكتب:

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

لكنني أفضل حقًا أن أرى:

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

على أي حال ، لقد فوجئت بأن نيكو كان يقصد أنه أحيانًا ما يجد هذه "ضرورية للغاية" ، لذلك أود سماع المزيد من الحجج المضادة. نظرًا لأنهم يجب أن يكونوا متخصصين ، يبدو الأمر أشبه بـ "شيء لطيف أن يكون لديك" أكثر من كونه أمرًا "ضروريًا للغاية" بالنسبة لي.

أشعر بالتأكيد أنه من الأسهل التأثير على أنماط النطاق الحصرية من تعبيرات النطاق الشامل.

حجة الاتساق

ذكر نيكو أن وجود كل من .. و ... في كل من التعبيرات والأنماط أمر مهم بالنسبة له بسبب الاتساق. أنا في الأساس غير متأثر بهذه الحجة. التكرار من خلال النطاق والمطابقة على نطاق ليسا عمليتين متماثلتين حقًا ، ومن المنطقي أنه ستكون هناك اختلافات بين الطريقة التي نتعامل بها معهما.

في الواقع ، لا يوجد اتصال تنفيذ: ينتج 1..10 قيمة نطاق ، بينما 1...10 يطابق قيمة عدد صحيح. ليس الأمر كما لو كان لديهم ارتباط هيكلي / مدمر بالطريقة التي تعمل بها معظم تعبيراتنا المتناسقة / تراكيب الأنماط.

يبدو أنه من الأصح من الناحية الفنية استدعاء أنماط "أنماط المجال" بدلاً من "أنماط النطاق" 🤓 ، مما يسلط الضوء على عدم الاستدلال.

تضمين التغريدة

على سبيل المثال ، يقول نيكو أن "أنماط النطاق الحصرية تبدو غير ملائمة حتى تريدها" ، لكنني اعتقدت أن نيكو وجوش كانا يتحدثان عن تعبيرات النطاق الشامل في ذلك الوقت.

من ناحيتي ، وجدت كل من النطاقات الحصرية والشاملة ضرورية في أوقات مختلفة (على الرغم من أنني استخدمت حصريًا لكلتا الحالتين للعمل على صدأ مستقر ، واضطررت إلى حلها باستخدام +1 في الجزء العلوي مرتبط ب). أرغب في إتاحتها لكل من الأنماط والتعبيرات.

بعد قولي هذا ، شخصيًا ، ليس لدي أي اعتراضات على استخدام دالة للنطاقات الشاملة ، باستثناء أنني أريد الحصول على طريقة لكتابة كل من النطاقات الشاملة والحصرية في الأنماط ، وأود ألا تبدو هاتان الصيغتان متشابهتين بشكل مربك مثل .. و ... . وبالنظر إلى التركيب اللغوي لكتابة مثل هذه النطاقات في الأنماط ، فأنا لا أعرف أنه من المنطقي وجود صياغة مختلفة لمثل هذه النطاقات في التعبيرات.

على وجه الخصوص ، الجانب السلبي الذي يشاركه كل حل نحوي هو أنه لا يوجد أي منها يقوم بالتوثيق الذاتي حقًا. من غير الواضح نسبيًا أن 0 ... 10 أو 0 .. = 10 عبارة عن تعبير نطاق شامل. نظرًا لأنه سيتم مواجهتها بشكل غير متكرر نسبيًا ، فسيكون هذا حجر عثرة للمستخدمين الذين يواجهونها لأول مرة.

أنا لا أتفق مع هذا. يأتي هذا بشكل غير متكرر لدرجة أنه ليس لدي أي اعتراض على بناء جملة أقل إحكاما. بيد أنني، ترغب في الحصول على بعض آلية لكتابة نطاقات شاملة وحصرية في كل التعبيرات والأنماط.

لا أمانع ، على سبيل المثال ، إذا تطلبت كتابة نمط نطاق شامل وحدة ماكرو أو ما شابه ذلك.

joshtriplett @ هذا هو المكان الذي أريد أن أكون واضحًا فيه حقًا ، عندما تقول هذا:

لقد وجدت كلاً من النطاقات الحصرية والشاملة ضرورية في أوقات مختلفة (على الرغم من أنني استخدمت حصريًا لكلتا الحالتين للعمل على Rust المستقر ، واضطررت إلى حلها باستخدام +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> */ }
    }

لن أقول إنه محبط بشكل خاص ، لكن الأول يبدو بالتأكيد أجمل.

withoutboats من أجل الوضوح ، أردت في أوقات مختلفة تعبيرات نطاق حصرية وتعبيرات نطاق شاملة وأنماط نطاق شاملة. لا يمكنني التفكير في وقت اهتممت فيه بشدة بوجود أنماط نطاق حصرية ، على الرغم من أنني أيضًا لن أعترض عليها. ولكن حتى إذا لم يكن لدينا أنماط نطاق حصرية ، فسأظل مربكًا للغاية إذا كانت أنماط النطاق الشاملة تستخدم ... وتعبيرات النطاق الحصرية تستخدم .. .

petrochenkov أفترض أن هؤلاء كان من المفترض أن ينتهي بـ F ، وليس C ؟

لقد واجهت نفس الحالة مع أنماط النطاق السداسي ، على سبيل المثال 0x8000...0x9FFF => /* body */ . أجد أن 0x8000..0xA000 يحتوي على خصائص حدسية أكثر قليلاً ، مثل دون الحاجة إلى التفكير في الأمر ، أرى على الفور أن حجم النطاق هو 0xA000 - 0x8000 = 0x2000 وأن النطاق المجاور التالي يبدأ من 0xA000 .

التعامل مع +1 المطلوب لرؤية هذه الحقائق في نطاق شامل هو اختلاف بسيط يمكنني التعايش معه ، لكن النطاقات الحصرية (كل من الأنماط والتعبيرات) تناسب عملي بشكل أفضل.

petrochenkov يمكنني معرفة سبب تفضيلك للنطاقات الحصرية لـ hexdigits (ما زلت ربما لا ، لكن هذا يبدو وكأنه صفقة YMMV للغاية).

كيف سنتعامل مع جوانب الغموض في تركيب الشريحة؟

تضمين التغريدة

ما زلت محيرًا للغاية إذا كانت أنماط النطاق الشامل تستخدم ... وتعبيرات النطاق الحصرية تستخدم .. .

هذه هي الطريقة التي يعمل بها Rust اليوم ولا يبدو أنه مصدر ارتباك مهم؟

تضمين التغريدة

أفترض أن هؤلاء كان من المفترض أن ينتهي بـ F وليس C؟

رقم :)
(هذه الأشياء 32 بت و offset مضاعف لأربعة.)

تضمين التغريدة

أستطيع أن أرى سبب تفضيلك للنطاقات الحصرية لـ hexdigits (ما زلت ربما لا ، لكن هذا يبدو وكأنه صفقة YMMV للغاية).

يجب أن أشير إلى أن هذا ليس تفضيلًا قويًا ، ما زلت على ما يرام مع إسقاط كل من الأنماط الحصرية والنطاقات الشاملة (ولكن ليس أحدها ، سيكون ذلك سخيفًا للغاية).

كيف سنتعامل مع جوانب الغموض في تركيب الشريحة؟

بسهولة! PATTERN.. => .. @ PATTERN

السبب الرئيسي لرغبتي في أن تكون النطاقات الشاملة بسيطة هو أنني واجهت مواقف أكثر من مرة حيث أقوم بتمرير قيمة إيقاف في متغير وهي بالضبط القيمة القصوى التي يمكن أن يحملها نوع متغير واحد ، لذا فإن الحلول الوحيدة لاستبعاد تجاوز في وقت الترجمة:

1. استخدام نطاق شامل (أنظف ولكن ليس ثابتًا)
2. البث قبل + 1 (بافتراض أنني لست مشتركًا بالفعل في u64 وأنني غير أنيق)
3. أخذ القيمة الأصغر والأقصى مطروحًا منها واحد للنطاق ، ثم تشغيل المهمة مرة أخرى إذا كان ذلك مناسبًا.

إن بناء عادة استخدام نطاقات شاملة بدلاً من إضافة + 1 إلى خوارزمية ليس لها غرض متأصل هو طريقة غير تافهة للحماية من مواجهتها مرة أخرى لاحقًا في cargo fuzz ... وباستخدام تعطي وظيفة "جعلها شاملة من حصرية" مع عدد أحرف أكبر من اسمها من + 1 انطباعًا بأن النطاقات الشاملة هي شيء استثنائي ، وليس شيئًا يجب أن تستخدمه بشكل معتاد.

هذا أحد أكبر أسباب معارضتي لها. إنه ينقل الانطباع بأن النطاقات الشاملة عبارة عن اختراق ، يتم استخدامه عند إثبات فشل النطاقات الحصرية.

ssokolow لكن حالة الاستخدام هذه مغطاة بشكل مريح بوظيفة تمهيدية. لا أحد يتخذ موقفًا مفاده أنه لا ينبغي أن يكون من الممكن إنشاء نطاقات شاملة ، فقط ما إذا كان ينبغي أن يكون لديهم سكر نحوي لإنشائها أم لا.

أحب فكرة withoutboats لوظيفة تمهيدية. أعتقد أن المكان الآخر حيث قد تكون النطاقات الشاملة أكثر شيوعًا هو عندما لا تستخدم الأعداد الصحيحة ، على سبيل المثال ، عن طريق تحديد حدود البحث على btree (أو بنية بيانات مماثلة).

withoutboats ، قمت بتحرير قليل على رسالتي أثناء الرد ، لكن جوهر ما أضفته هو أن جعل النطاقات الشاملة مواطنين من الدرجة الثانية ، من الناحية التركيبية (مع بناء جملة أطول من إضافة + 1 إلى نطاق حصري ) ، يبدو وكأنه إحباط خفي ضد استخدامها و "سأراك في cargo fuzz لاحقًا".

إذا لم يكن هناك شيء آخر ، فهو ثؤلول قابلية التعلم.

Rust ليس Python 3.x ، مع دعم عدد صحيح غير محدود. لا يخفي Rust مقايضات الأجهزة عن المستخدمين ، وأرى ..= الذي أفضله كجزء من استخدام u32 والأصدقاء بدلاً من int . (خاصة وأن أخطاء تجاوز / تجاوز السعة هي أكثر الأشياء شيوعًا في "حقيبة الجوائز" الخاصة بـ cargo fuzz حتى الآن.)

تحرير: الرجاء تجاهل أي بتات تراها فقط في إشعارات البريد الإلكتروني لهذا الغرض. لقد استيقظت للتو ولم أكن أطلق النار على جميع الأسطوانات بعد.

لا أرى inclusive(n..m) مثبطًا للتشجيع على الإطلاق ... أفضل كتابته لأنه بناء واضح جدًا يجعل قراءة الكود أسهل من قراءة كل من n..(m + 1) و n..=m (والذي جئت لأعتبره غريبًا بشكل غير ضروري عندما يمكننا أن نقول كلمة "شامل").

n..=m هو أكثر ثؤلول قابلية للتعليم من inclusive(n..m) IMO.

أعتقد أنه بالنسبة للمطابقة ، هناك رغبة في الحصول على تغطية كاملة للنطاق الرقمي ، بدلاً من نوع معين من الأنماط.

من المفترض أنه إذا كان هناك بناء جملة "متابعة من السابق" ، فسيؤدي ذلك أيضًا إلى حل المشكلة.

راجع للشغل ، نظرًا لأن النمط الأول فقط يطابق ، يمكن غالبًا حذف رقم البداية:

    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 منذ المدرسة الابتدائية ، إنه قصير وسهل الكتابة ، ونفسي عديم الخبرة معتاد على العمل بلغات مثل Python و JavaScript حيث تسبب الإضافة في التدفق ليس شيئًا قلقًا بشأنه.

تحرير: ... وهذا التمييز المفاهيمي في النقطة 1 الذي أعتقد أننا يجب أن نركز عليه. (على سبيل المثال ، يجب أن تكون "من X إلى المحور" و "من X إلى النهاية" مميزة في ذهن المبرمج.)

تضمين التغريدة
هذا فظيع 😄
في هذه الحالة المحددة ، يعد بدء النطاق أمرًا مهمًا حقًا بالنسبة للشخص الذي يقرأ الكود ، وهو أكثر أهمية بكثير من أي مشكلات نطاق شامل / حصري.

ssokolow يبدو لي أن ما يجعل +1 مشكلة ليست في عدد الأحرف ولكن عليك التعامل مع احتمال تجاوز السعة. كما أنه لا ينقل النية أيضًا ، ويتطلب أسبقية الجدال. كل هذه تبدو أكثر أهمية من عدد الأحرف.

قد يصل الشخص الحقيقي الذي لا يعرف عن الفائض إلى +1 قبل إنشاء نطاق شامل ، لكن هذا لا يبدو معتمدًا على بناء الجملة. اكتشف كلاهما أن ..= يعد شيئًا وأن inclusive() شيء يمثل لحظة قابلة للتعليم لمعرفة سبب رغبتك في نطاقات شاملة على وجه التحديد.

تضمين التغريدة

ما زلت على ما يرام مع إسقاط كل من الأنماط الحصرية والنطاقات الشاملة (ولكن ليس أحدها ، فسيكون ذلك سخيفًا للغاية) .

هل يمكنك التوسع في الحديث عن سبب شعورك بهذه القوة تجاه هذا الأمر؟ أرى بالتأكيد أن قبول الأنماط الحصرية له جانب سلبي لأنه قد يدفع المستخدمين إلى توقع 0...10 كتعبير ، لكن لا يبدو ذلك سيئًا بالنسبة لي.

يتمثل جزء من مشكلتي مع inclusive() أنها وظيفة "فقط" وأنا قلق من قيام الأشخاص بأشياء مثل الانتقال إلى فهرس بنية Rust ، والبحث عن "النطاق" أو "المكرر" ثم افتراض عائد استثمار غير كافٍ عن "راجع التكرارات".

("لا أريد أن أقرأ كتابًا دراسيًا إذا وجدت شيئًا مفيدًا ... أريد فقط التكرار على نطاق واسع والعودة لإحراز تقدم.")

withoutboats إذا كان لدينا شامل (a..b) ، لكن لا يمكننا استخدامه في المباراة ، فلا يستحق الأمر IMO.
في معظم الأوقات عندما أستخدم النطاقات الشاملة ، يكون ذلك في أنماط المطابقة!
فلماذا لا يمكننا إزالة ... واستخدام ..= داخل وخارج المطابقة؟

Boscop ، لا يتمثل الاقتراح في إزالة ... في المطابقة ، ولكن ترك الأنماط كما هي في حالة مستقرة.

يبدو أن ssokolow يمكن حله بسهولة تامة من خلال ملاحظة في قسم ..

withoutboats ولكن لماذا لا تزيل ... في المطابقة وتستخدم ..= بدلاً من ذلك ، لذا فهي متسقة؟
(بحيث يكون ..= داخل وخارج المطابقة)

لتغطية النطاق الرقمي في النقطة العائمة ، يساعد حصري. على سبيل المثال ، إحدى هذه الحدود مغطاة بالكامل وليس الأخرى:

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

وبدلاً من ذلك ، فإن كتابتها مع التداخلات تبدو رديئة (وتشبه أخلاقياً "فقط ابدأ كل شيء من -∞ منذ ترتيب الأسلحة" أعلاه). راجع أيضًا التواريخ ، مثل كيف تسمح ISO8601 بـ T24: 00 ، نظرًا لأن اليوم هو [00:00 ، 24:00) ، وليس [00:00 ، 23:59:59]. أو سلاسل ، أو مبررات ، أو ...

بالنظر إلى الاختيار الحصري فقط أو الشامل فقط ، سآخذ حصريًا في كل مرة.

(جانباً: من الأفضل تنفيذ النمط 1 <= x <= N للفهرسة كـ 0 < x <= N ، وهو أيضًا حصري - على الرغم من أنه نصف مغلق بدلاً من نصف مفتوح - للأسباب نفسها التي قالها Dijkstra ، فقط حول الفهرسة المستندة إلى 1 بدلاً من المستندة إلى 0.)

كان من الممكن أن يكون هذا المشغل مفيدًا للغاية لوظيفة المشبك التي اقترحتها هنا: https://github.com/rust-lang/rfcs/pull/1961 ولكن نظرًا لعدم استقرار هذا ، ربما يتعين علي تعديل هذا الاقتراح إلى استخدم وسيطتين min و max بدلاً من ذلك. إن InclusiveRange مفيد جدًا عند التعامل مع قيم الفاصلة العائمة أيضًا ، لذلك لا يتعين علينا القيام بشيء مثل:

0.0..1.0 + EPSILON

لست متأكدًا حتى من صحة ذلك ، ولكن في الوقت الحالي من الصعب جدًا الإعلان عن نطاق شامل لأرقام الفاصلة العائمة.

الطريقة الصحيحة للقيام بذلك ستكون باستخدام nextafter ، وليس باستخدام epsilon. على سبيل المثال ، 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 بمطابقة الأنماط ، وبالتالي لا يلزم أن يكون متسقًا معه.

تضمين التغريدة

لسوء الحظ ، ليس لدي إجابة جيدة لما يجب فعله حيال ذلك ، على الرغم من أن طلب .into_iter () شاملاً ولكن ليس حصريًا سيكون أمرًا مؤسفًا أيضًا ...

ربما يمكننا إضافة مساعد مثل range.nonempty() الذي يفزع من نطاق فارغ ، ويعيد زوجًا؟

بدلاً من ذلك ، يمكننا تنفيذ IntoIterator مقابل RangeInclusive ولن يكون بعيدًا جدًا عن IMHO.

ما حالة استخدام خدمة RangeInclusive :: Empty؟ لماذا يحتاج النطاق الشامل إلى القدرة على تمثيل نطاق فارغ؟ كيف تكتب واحدة؟ (لاحظ أنه يمكنك بالفعل كتابة أشياء مثل "النطاق من 5 إلى 4 ، شاملًا" ، والذي من المفترض أن يعامله التكرار على أنه فارغ.)

joshtriplett ، الحالة الرئيسية هي تجاوز السعة ، على الرغم من وجود طرق لحل هذه المشكلة.

joshtriplett start > end لا يعمل في الواقع لتمثيل النطاق الشامل الفارغ في حالة واحدة مهمة: 0u8...255u8 . عندما تصل إلى 255u8...255u8 وتحاول .next() ذلك ، ستصاب بالذعر أو الالتفاف إلى 0u8...255u8 ، وهو ليس فارغًا. لذا بدلًا من ذلك ننتقل إلى المتغير Empty في تلك المرحلة.

solson آه ، فهمت. نعم ، هذا أمر مؤلم ، وهو أحد أكبر حالات الاستخدام للنطاقات الشاملة.

(أفترض أنك تعني 255u8 في كل هذه الحالات.)

(أفترض أنك تقصد 255u8 في كل تلك الحالات).

نعم شكرا. تم تحريره.

ومع ذلك ، يمكن تصحيح هذه الحالة solson عن طريق تبديل 0 و 255 في هذه الحالة

تضمين التغريدة نظرًا لأن .next() يضطر دائمًا إلى إنشاء نطاق Empty بحالة خاصة ، فيمكن دائمًا إنشاء نطاق يتم التعامل معه على أنه فارغ.

أنا شخصياً أحب هذه الطريقة بشكل أفضل لأنها لا تتضمن النطاق الفارغ.

لذا فإن هذا الخيط مستمر منذ عام ونصف. لقد انتهيت للتو من قراءة كل ذلك وأود أن أنشر ملخصًا موجزًا ​​للوافدين الجدد وأتمنى أن تساعدنا في التوصل إلى قرار:

ما يفعله Rust Stable اليوم:

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) تقوم تلقائيًا بتحويل المصادر من استخدام ... في النمط المطابق للبنية الجديدة (على سبيل المثال ..= ) عندما يتم تحديد ذلك.
وبهذه الطريقة لن نتراجع عن "كل الشفرات المكتوبة بالطريقة القديمة" ..
ولكن يجب الاستناد إليه بنية من مؤلفي المشروع ويجب أن يكون هناك إشعار / عنوان رئيسي على جميع وسائط الصدأ حتى يكون الجميع على دراية بالتغيير.
مع هذه الأشياء ، أعتقد أنه لا توجد مشكلة في تغيير بناء الجملة ... في مطابقة النمط للصيغة الجديدة.

أعتقد أن أحد الأشياء التي يمكننا القيام بها للتغلب على مشكلة بناء الجملة هو مجرد تثبيت RangeInclusive ، كما اقترح clarcharr . سيؤدي هذا إلى إلغاء حظر الناس على الأقل.

يمكننا أيضًا إضافة الوظيفة inclusive (إما فقط إلى std::range أو ربما إلى المقدمة أيضًا) ؛ هذا لا يمنع وجود بناء جملة من الدرجة الأولى يومًا ما ولكنه يجعل الأمر أكثر ملاءمة لإنشاء RangeInclusive الآن.

ومع ذلك ، فإن كل هذه تبدو وكأنها قرارات libs ، لذا لا أعرف ما إذا كان فريق lang يتمتع بالسلطة القضائية لتقرير تثبيت / إضافة هذه العناصر 😅.

أنا شخصياً أفضل تحويل RangeInclusive نفسه إلى شيء لا يحتوي على متغير Empty ، ثم اجعل المتغير IntoIter . من المنطقي أكثر بالنسبة لي التفكير في كيف أنه من المستحيل أساسًا إنشاء نطاق فارغ دون استخدام Empty { at } يدويًا.

بدلاً من ذلك ، قم بتبديل MAX و MIN في حالة الحافة الواحدة التي ذكرتها. هذا يجعل من الصعب كتابة رمز أكثر عمومية يتضمن RangeInclusive ، لكن يبدو أنه حل معقول للمشكلة.

بغض النظر عما يحدث ، فأنا أؤيد بشدة تثبيت النوع في المكتبة القياسية ، والتي ستكون موجودة بغض النظر عن مخاوف بناء الجملة. يسمح للمكتبات بكتابة رمز ثابت يسمح بالتقطيع بنطاقات شاملة ، بحيث بحلول الوقت الذي يتم فيه تثبيت بناء الجملة ، يكون الأشخاص قد نفذوا بالفعل الكود الذي يستخدم الأنواع. تعد البنية والأنواع تحت علامات ميزة مختلفة لسبب ما.

scottmcm أوافق على أنه ربما يجب أن يكون موضوعًا منفصلاً في هذه المرحلة.

في محاولة لمواصلة المضي قدمًا في مناقشة بناء الجملة ، سأعرض المسار الذي أفضل اتباعه.

أنا مغرم جدًا ببنية ..= ، لذلك أشعر أنه يجب علينا إضافة هذا السكر النحوي على أنه يساوي ... في مطابقة النمط وكإضافة InclusiveRange خارج مطابقة النمط. ثم من أجل الحفاظ على اتساق اللغة ، يجب أن نحاول ترحيل المستخدمين وكودهم إلى بناء جملة ..= في الأنماط ، باستخدام الإعلانات والأدوات الآلية. بمجرد أن نشعر أننا قمنا بترحيل عدد كافٍ من المستخدمين بعيدًا عن ... يمكننا جعل استخدامه تحذيرًا للمترجم ، ثم في النهاية (ربما حتى سنوات من الآن) خطأ في المترجم.

لقد مر 24 يومًا منذ تقديم اقتراحي ولم يتم الإدلاء بأي تعليقات. هل يجب أن نمضي قدما بهذه الخطة؟

تحرير: على الهاتف المحمول لم أر إهمالًا ، لذلك لم أدرك أن هناك آراء معارضة.

تضمين التغريدة لا أوافق على أن إهمال ... لصالح ..= هو اختيار جيد لأسباب قمت بنشرها بالفعل في سلسلة الرسائل هذه. لم أرد على اقتراحكم المحدد لأنه تم طرح الفكرة نفسها ومناقشتها بالفعل. الشيء الوحيد الواضح هنا هو أنه ليس لدينا إجماع. أعتقد أن الكثير منا يشعر بالإرهاق من المناقشة.

تعديل: لكي أكون أكثر تحديدًا ، لا أريد إهمال ... لصالح ..= للأسباب التالية:

• إن إهمال بناء الجملة هو تكلفة باهظة في الزخم ؛ حتى لو أحببت بشكل فريد ..= لا أعتقد أنه سيكون من المجدي دورة الإهمال لمجرد الحصول على تعبيرات النطاق الشاملة على مستقر.
• لا أحب ..= ، أعتقد أنه غير واضح وغير واضح ؛ لديه ميزة أنه من غير المحتمل أن يؤدي إلى حدوث خطأ واحد ولكن هذا لا يعني أن المستخدم ، عند رؤيته لأول مرة ، سيعرف ما الذي يبحث عنه.
• لا أتفق مع الفرضية القائلة بضرورة وجود تناسق بين الأنماط والتعبيرات هنا ، لأنها لا تقوم بأي نوع من عمليات الهيكلة / التدمير المماثلة.

(قمت بتغيير وجهات النظر قليلاً أثناء هذا التعليق ، قررت ترك كل شيء حتى يتمكن الآخرون من رؤية عملية تفكيري ولماذا توصلت إلى الاستنتاجات التي قمت بها)

لا يمكنني التعليق حقًا على تكلفة الإهمال بسبب قلة خبرتي في مثل هذه الأشياء. ومع ذلك ، ما زلت أؤيد ..= .

أعتقد أنه في مرحلة معينة يجب أن نكون مستعدين لمطالبة المستخدمين بتعلم شيء ما. البرمجة ككل شيء يجب تعلمه ، البنية المتخصصة بشكل عام تأتي دائمًا بتكلفة معينة للدلالات. لا أتوقع أن يتعرف الناس على بناء الجملة للوهلة الأولى ، .. هو نفس السوء في هذا الصدد.

ومع ذلك ، فإن وجود وفرة في بناء الجملة المتخصصة يمكن أن يؤدي إلى لغة تبدو أقرب إلى عقول الدماغ مما نريد أن يكون عليه Rust. لذلك علينا أن نكون حريصين على أن الحالات التي نختار تحويلها إلى صيغة خاصة هي في الواقع شائعة بما يكفي لتكون جديرة بذلك. لأكون صادقًا الآن بعد أن كتبت هذا ، لست متأكدًا تمامًا من أن هذه الحالة تستحق ذلك. الحاجة إلى نطاقات شاملة ليست عالية بما يكفي لتبرير بناء الجملة.

لكن التناقض ما زال يزعجني. إن الحصول على وظيفة شاملة و ... في النمط المطابق نوعًا ما يبدو وكأنه يحتوي على الرمادي والرمادي في اللغة الإنجليزية. عندما تتاح لنا الفرصة لتوحيد أن يشعر جزء مني أنه ينبغي علينا ذلك. هناك أيضًا مشاكل لوجستية فعلية في إجراء هذا التغيير. إذا أردنا تصميم Rust 2.0 (قد يكون ذلك مجنونًا ، وليس لدي أي فكرة) ، فربما يتعين علينا إعادة النظر في هذا ولكن أعتقد الآن أن كلا من الرمادي والرمادي أمر جيد بما فيه الكفاية.

أنا أؤيد استخدام دالة inclusive للحالات خارج مطابقة النمط و ... في مطابقة النمط في هذا الوقت.

تضمين التغريدة

1. إذا لم تقم أبدًا بإهمال أي شيء ، فسوف ينتهي بك الأمر مع اتحاد جميع القرارات السيئة (أكثر أو أقل) مثل C ++. هذا يجبر المبتدئين على تعلم المزيد لأن الأشياء ليست متسقة كما يمكن أن تكون.
   لذلك أحيانًا يكون من المنطقي إهمال الأشياء لإفساح المجال لحل أفضل.

2. هذا لا يعني أن المستخدم ، عندما يراه للمرة الأولى ، سيعرف ما الذي يبحث عنه.

هذا هو الحال مع أي بناء الجملة. نحن (الذين يعرفون Rust) لدينا هذا التحيز لأنه بالنسبة لنا ، يبدو رمز Rust واضحًا ولكن أي شخص يأتي إلى Rust من لغة أخرى عليه أن يبحث في كثير من الأحيان عن بناء الجملة. لا يتغير إذا استخدمنا ..= أو ... أو أي صيغة أخرى للنطاقات الشاملة لأن اللغات الأخرى ، على سبيل المثال ، تستخدم ... للنطاقات الحصرية ، لذا يتعين عليهم البحث عنها على أي حال .
لا ينبغي أن يكون هدفنا تقديم ميزات المظهر الواضحة فقط:
إذا أردنا الحصول على الميزات التي تبدو واضحة فقط ، فلا يمكننا الحصول على معظم الميزات الموجودة في Rust. نوبي بد من النظر في وثيقة على أي حال، ما هو الخطأ في ذلك؟ المستند جيد!

1. 
   إذا كنت مهتمًا بتقليل الأوقات التي يجب أن ينظر فيها المبتدئون إلى المستند ، فيجب أن نسعى جاهدين لتحقيق التناسق بين البناء ومطابقة النطاقات الشاملة! (والتركيبات الأخرى)

كما قال withoutboats ، أعتقد أن الكثيرين منا قد سئموا من هذه المناقشة ؛ لقد كنت أجلس في الخارج لفترة من الوقت. بعد قولي هذا ، استغرقت بعض الوقت لإعادة القراءة (شكرًا على الملخص Xaeroxe!) وإعادة النظر في أفكاري هنا.

IMO ، المشكلة الأكثر أهمية في الوقت الحالي هي التركيبة غير الكاملة من الصيغ التي نقدمها : ... في الأنماط ، .. للتعبيرات. يقودك هذا الزوج من التركيبات بشدة إلى توقع أن .. سيعمل في الأنماط و ... في التعبيرات - لكنهما لا يعملان. أعتقد أن هذا ليس تصميمًا يمكن الدفاع عنه على المدى الطويل ، وأريد حقًا إصلاحه.

أعتقد أيضًا أنه نظرًا لأننا قدمنا ​​بناء الجملة لكلا النوعين من النطاقات ، فمن الأفضل الاستمرار في القيام بذلك. هذا يترك لنا خيارين:

• ثبّت تعبيرات ... وأضف .. إلى الأنماط. هذا هو التغيير الأقل إيلامًا ، ولكنه يحتوي على جوانب سلبية تمت مناقشتها جيدًا حول الأخطاء الفردية. ومع ذلك ، فإن اللغات الأخرى لديها هذا المزيج ولم تتعرض ، على حد علمي ، لمثل هذه الأخطاء بشكل رهيب.

• استبعد ... في الأنماط والتعبيرات ، وأضف ..= لكليهما ، وأضف .. إلى الأنماط. يعمل على حل الجوانب السلبية أعلاه ، وهو أكثر إيلامًا (بسبب الإهمال) ، ويفتح الباب لأنواع أخرى من النطاقات (مثل اليسار الحصري) في المستقبل.

في هذه المرحلة ، أعيد صياغة النقاش إلى حد كبير ، وبصراحة ، لا أعتقد أن هناك الكثير مما يمكن قوله في هذه المرحلة ؛ أعتقد أننا كشفنا المفاضلات ونحتاج فقط إلى فريق لانج لإجراء تقييم والتوصل إلى قرار. لكن الدافع الرئيسي لتعليقي هو النقطة الأولية ، حول لماذا أعتقد أن شيئًا ما يحتاج إلى التغيير هنا (ولماذا مجرد إضافة inclusive لا يكفي ، IMO).

ومع ذلك ، فإن اللغات الأخرى لديها هذا المزيج ولم تتعرض ، على حد علمي ، لمثل هذه الأخطاء بشكل رهيب.

أنا قلق بشأن تحيز الاختيار هنا. ليست لدينا طريقة موثوقة للحكم على ما إذا كانت المشاكل بسيطة أم أنها نادراً ما تلفت انتباهنا.

أيضًا ، فإن استخدام ... يبدو أنه يتعارض مع جانب "تجنب المسدسات ما لم تكن المقايضات شديدة جدًا" لفلسفة تصميم Rust وأفضل الممارسات الناشئة. (على سبيل المثال ، النصيحة لإنشاء أنواع enum بدلاً من استخدام bool لذلك يصعب الخلط بين معلمات الوظيفة.)

على سبيل المثال ، أثبتت C أن المهمة في كشوفات حساب if مفيدة إذا لم يكن للغة while let ، ولكن تم التعرف على أن كتابة = عندما كنت تقصد == يكفي من مسدس قدم ترفضه لغات مثل Python ، حتى في حالة وجود مواقف تكون فيها البدائل الوحيدة قبيحة بشكل غير معهود.

الذهاب في الاتجاه الآخر ، لقد تلقيت بالفعل Clippy في حالة مثل هذه عندما كنت متعبًا من الترميز منذ حوالي أسبوع ...

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. من المحتمل أن يكون الأشخاص على دراية بـ ... تعني "الراحة" من لغات مثل CoffeeScript (تستخدم CoffeeScript rest... في تواقيع الدالة للفرارجس وتسميها "splats") واللغة الإنجليزية (باستخدام Unicode الصحيح نقطة الشفرة أم لا ، إنها ثلاث فترات تبدو وكأنها علامة حذف ، وليست أربع فترات ، ويقوم الأشخاص بعمل لائق في فهم علامات الحذف لتعني تقريبًا "وهناك المزيد ولكننا لا نقولها بصوت عالٍ" باللغة الإنجليزية ، فقط من مواجهتها في الاستخدام.)

2. ما لم أفتقد شيئًا عن بناء جملة Rust ، فإن استخدام .. و ..= للنطاقات ولكن ... لشرائح الباقي يعني أنه في كل حالة ، كتابة ... عندما تقصد .. أو العكس ، فسيظل خطأ في وقت الترجمة.

   لهذا ، أنا أعمل على افتراضين:

   1. لن يُسمح باستخدام صيغة الراحة وحدها (خارج سياق تفريغ التسلسل) باعتباره عدم وجود أخطاء مطبعية. (على سبيل المثال ، سيكون for _ in ...rest هو نفسه for _ in rest إذا كان مسموحًا به ، ولكن من شبه المؤكد أنه خطأ إملائي.

   2. استخدام نطاق مفتوح كنمط يتم تعيينه سيكون غير صالح. (مثال: let [first, ..rest] = سيكون غير صالح.)

ssokolow triple dot تعني بالفعل نطاقًا في النمط بحيث يكون تغييرًا

phaux نقطة. لقد نسيت ذلك لسبب ما.

ربما يكون هناك شيء يمكن تعليقه عن علامة "إذا صنعنا Rust 2.0".

تعني النقطة الثلاثية بالفعل نطاقًا في النمط بحيث يكون تغييرًا مفاجئًا لتغييره إلى بناء الجملة.

ومع ذلك ، يجب أن تحتوي الأنماط ... في كلا الجانبين ، على ما أعتقد ( a...b ) ، بينما تستخدم الصيغة المتبقية ... كبادئة ، أليس كذلك؟

ناقش فريق lang هذه الميزة مرة أخرى في اجتماعنا اليوم ، وتوصلوا تقريبًا إلى المصفوفة التالية:

• دعم ... في الأنماط و .. في التعبيرات ، ولا شيء آخر ، هو تصميم لا يمكن الدفاع عنه ؛ يقود المستخدمين إلى توقع أن بناء الجملة لن يعمل.

• إن السماح بدولار ... و .. في كلا المكانين من شأنه أن يساعد ، لكن مشكلة `` كل على حدة '' هي مصدر قلق حقيقي ؛ لا أحد منا حريص على تلقي تقارير عن أشخاص يقضون ساعات في تعقب فترة ضالة.

• يعد الانتقال إلى ..= و .. أقل جاذبية من الناحية الجمالية ، لكنه يتجنب المشكلات العملية الحقيقية للغاية المذكورة أعلاه. يمكننا أيضًا طرحها بطريقة لطيفة جدًا: أولاً ، أدخل ..= كبديل (يمكن لـ rustfmt إعادة الكتابة إليه) ، وبعد أن تصبح اصطلاحية فقط ، قم بإهمال ... .

في حالة عدم قدرتك على معرفة ذلك ، يشعر الفريق أن ..= و .. هو أفضل طريق للمضي قدمًا. تمت مناقشة هذه المشكلة أيضًا إلى درجة أنه من غير المحتمل جدًا طرح حجج جديدة ، لذلك نحن على استعداد لأخذ زمام المبادرة: نحن نبحث عن شخص يرغب في تنفيذ ترميز ..= لكليهما الأنماط والتعبيرات ، وبعد ذلك سنذهب إلى FCP!

لتحقيق هذه الغاية ، نبحث عن شخص ما (أو بعض الأشخاص) لدفع التنفيذ إلى الأمام. ربما يمكن القيام بذلك في عدد من العلاقات العامة الأصغر:

• للبدء ، دعنا نضيف ..= إلى المحلل اللغوي كاسم مستعار لـ ... ونحول الاختبارات الحالية.
  
  
  
  • يجب أن يستمر ... العمل ، بالطبع ، ونريد أن يكون هذا إهمالًا "صامتًا" ، لذلك ليست هناك حاجة لإصدار تحذيرات وما إلى ذلك (حتى الآن).
  
  
  • سنحتاج بالتالي إلى الاحتفاظ بالاختبارات على أنماط ...
  
  
  • أعتقد على الأرجح طريقة للقيام بذلك هو تعديل في lexer بإضافة DotDotEquals رمز ( هنا هو موجود DotDotDot ) ثم تعديل محلل لقبول DotDotEquals في كل مكان نحن قبول الآن DotDotDot ( مثال )
  
  
  • ripgrep DotDotDot صديقك هنا ؛)
  
  
• لم تكن التعبيرات ... مستقرة على الإطلاق ، لذا يمكننا تغيير ذلك إلى ..= وقتل الدعم الأقدم
  
  
  
  • لكي نكون لطيفين مع الناس في البرية ، يمكننا أن نمر بفترة إهمال ، لكنني لست متأكدًا من أن هذا ضروري (أفكار؟)
  
  

فقط للإشارة إلى أنه عند التنفيذ ، لا يجب تغيير بناء الجملة extern fn foo(a: u32, ...) إلى ..= 😆

تميل إلى أخذها لأنها تبدو كخطوة أولى لطيفة في الكود ، لكنني لن أحظى بالكثير من الوقت في الأسبوعين المقبلين ، لذا إذا أراد أي شخص استلامها ، فلا تتردد!

أنا شخصياً أؤيد ..^ أكثر من ..= ، لأن a operator= b هو بالفعل ، لبعض المشغلين ، اسم مستعار لـ a = a operator b . من ناحية أخرى ، يتم استخدام ^ أقل بكثير ، فقط لـ XOR ، لذلك يجب أن يسبب ارتباكًا أقل.

ينتج عن .. نوعًا مختلفًا عن نوع المعاملين الأيمن والأيسر له ، لذلك لا أرى أن هذه مشكلة بالنسبة إلى ..= . يساعد السياق أيضًا في تحديد الغرض من المشغل ، شيء مثل += يُرجع () لذا يمكن أن يظهر كبيان خاص به ، عادةً في السطر الخاص به. بينما يُرجع ..= InclusiveRange لذا سيظهر كتعبير داخل الإرشادات الأخرى. وعلاوة على ذلك النحو المذكور أعلاه ..^ تبدو مثل ذلك له علاقة مع الأسي من مجموعة.

Xaeroxe ^ ليس له علاقة بالصدأ مع الأُس (على الرغم من استخدامه في لغات أخرى) ، بينما += ، -= ، *= all موجودة في الصدأ. في الواقع ، حتى ^= موجود.

لكن لا يهم ، من الجيد أن يكون لديك ..= أيضًا.

منذ أن تم دمج # 42134 ، هل يمكننا التحرك لتثبيت هيكل المكتبة الآن؟ أعتقد أننا سنرغب في انتظار استقرار بناء الجملة قبل تثبيت ذلك ، على الرغم من أنه كما قلت سابقًا ، سيكون من المفيد تثبيت البنية في وقت أقرب.

clarcharr أعتقد أننا توصلنا إلى قرار تثبيت هذا الهيكل بالإضافة إلى بناء جملة ..= لذلك نحن فقط بحاجة إلى بعض العلاقات العامة للقيام بذلك بالفعل.

تحرير: Woops كنت مخطئا. نحن ننفذها في المترجم ، وسيحتاج تثبيت البنية إلى انتظار انقضاء فترة التعليق النهائية. أعتقد أنه يجب علينا تثبيت الهيكل في هذا الوقت ولكن هذا ليس قراري أيضًا.

توقفت عن متابعة الموضوع منذ فترة طويلة ، عندما بدا لي أن ... كان يحقق الإجماع. ..= محرجًا بالنسبة لي لأنه يبدو وكأنه تأثر للوهلة الأولى.

لكن الأهم من ذلك بكثير ، لا أعتقد أن هذا التعرق بالدراجات مهم بدرجة كافية لتغيير بنية النمط الحالي.

هذا النحو تمتص!
= لها معنى التخصيص ، حتى في + = ، - = ، * = النموذج ، لكن .. = يتعلق بالحصول على شيء ما. مرتبك جدا وقبيح.
مثل فهرس المصفوفة يبدأ من 0 ، "..." جيد وجميل ، الناس سوف يعتادون عليه.

تضمين التغريدة
مشتق ..= من الناحية المفاهيمية من عوامل تشغيل مثل == و <= ، والموجودة بالفعل في Rust وتشير إلى مقارنة المساواة ، وليس التعيين.

(على سبيل المثال ، 1..=5 اختصار لعبارة "النطاق فوق القيم 1 <= x <= 5 " على عكس 1..5 بمعنى "النطاق فوق القيم 1 <= x < 5 ")

تحرير: أيضًا ، لا يتعلق الأمر بـ "التعود عليها" ، إنها مسألة يصعب قراءتها بشكل خاطئ أو كتابتها بشكل خاطئ عندما تكون متعبًا أو مشتتًا. تشتهر مثل هذه الأخطاء الفاصلة بخطوات بخطوة واحدة.

لقد كتبت عن طريق الخطأ ... عندما كنت أعني .. بالفعل. لحسن الحظ ، أستهدف دائمًا الصدأ المستقر ، لذلك اكتشفه المترجم. (ومع ذلك ، لا أستطيع أن أتذكر ما إذا كان ذلك تشنجًا عضليًا أو ذاكرة عضلية على افتراض أنني أردت كتابة علامة حذف زائفة لأنني أقوم بالكثير من الكتابة غير الخيالية.)

zengsai ... دقيق جدًا ، يبدو مشابهًا جدًا لـ ..

سيكون من غير الطبيعي حقًا أن تحتوي اللغة على عدد مختلف من النقاط التي تعني أشياء مختلفة

تعد إزالة مسدس القدم أكثر أهمية من أن تكون جذابة من الناحية الجمالية.

الوافدون الجدد: لقد صنعت TL ؛ DR ، لأن هذا خيط طويل جدًا. يمكنك قراءتها هنا: https://github.com/rust-lang/rust/issues/28237#issuecomment -296310123

عند التحدث إلى "أخطاء غير متوقعة مثل تلك التي تشتهر بها مسدس القدم" ، يجب أن أقول: لا ينبغي استخدام مشكلة الخطأ المطبعي كسبب رئيسي لهذا التغيير.

انظر إلى هذه المقارنة ، ".." و "..." vs "=" و "==" ، فهل هذا يعني أنه يجب علينا إيجاد صيغة أخرى لـ "==" لتجنب مشكلة الخطأ المطبعي للمستخدم؟ إذا كانت "=" و "==" على ما يرام ، فلماذا لا تستطيع ".." و "..."؟

لقد كنت أتابع رست لانج منذ أكثر من عامين. تم استخدامه في العديد من مشروعي الخاص. أحبه ، لكن بناء الجملة هذا جعلني أشعر بعدم الارتياح حقًا. ليس فقط من الناحية الجمالية ، بل إنه يؤثر أيضًا على طلاقة الكتابة والقراءة.

zengsai ، كنت أفهم أن الأمر لا يتعلق أساسًا بوقت كتابة الكود ، ولكن عند مراجعة الكود وقراءته وفهمه. إذا كنت لا تبحث عنه ، فمن السهل أن تفوت .. مقابل ... كونه خطأ متقطعًا ، بينما ..= يبرز بالتأكيد أكثر ويفوز ليس لدينا هذه المشكلة.

لست متأكدًا من أنني أحب بناء الجملة ..= إما من وجهة نظر جمالية ، لكن يمكنني أن أرى من أين أتى الجميع من قراءة حوالي .. و ... بشكل مشابه جدًا.

zengsai لأن = مقابل == يحتوي على حل غير متاح لـ .. مقابل ... .

بالتأكيد ، يمكنك الخلط بين = و == في C ... لكن هذا مسدس قدم معروف ولغات أكثر حداثة مثل Python و Rust حل ما يلي:

1. إنه خطأ إذا قمت بكتابة if x = y بدلاً من if x == y (هذا هو الإصلاح الذي صنعه Rust و Python)
2. عندما كتبت بالخطأ x == y; بدلاً من x = y; ، تلقيت تحذيرًا بشأن تعبير ليس له أي تأثير.

لا توجد طريقة حتى يدرك المترجم أن الارتباك .. مقابل ... أمر مريب ، ناهيك عن الخطأ.

zengsai .. و ... تقييم الأنواع التي تنفذ جميع السمات نفسها ويمكن استخدامها بشكل تبادلي (هذا حسب التصميم). إن الخروج بخطأ واحد هو مشكلة حقيقية للغاية.

أريد أن أوضح أنني أكره أيضًا بناء الجملة هذا ، لدرجة أنني لا أتفق مع تعليق aturon بأن الوضع الحالي حيث نستخدم .. والتعبيرات و ... في الأنماط "لا يمكن الدفاع عنها ؛" في الواقع ، أعتقد أنه من الأفضل قطع الاتصال بدلاً من الحصول على بناء الجملة هذا.

لكن من الواضح أنه لن يكون لدينا إجماع على هذا أبدًا ، وأنه لا توجد حجج جديدة يمكن طرحها حول هذا الموضوع ، وأن غالبية المستخدمين المستثمرين بنشاط (بالإضافة إلى بقية فريق اللغة) فضلوا هذا التغيير. لذلك أنا أقف جانبًا حتى نتمكن من حل المشكلة.

إذا كان هناك أي عزاء في تجربتي ، فإن الغالبية العظمى من حالات الاستخدام لا تحتاج أبدًا إلى هذه الميزة حقًا ، وبالتالي لن تظهر في جميع أنحاء التعليمات البرمجية الخاصة بك.

في الواقع ، ما زلت غير سعيد حقًا بشأن إهمال أنماط ... ، وسأقوم في الأساس فقط بحزم أسناني حتى يمكن حل هذه المشكلة. يوافق فريق lang بأكمله على أن استخدام تعبيري .. و ... سيكون ثؤلولًا رهيبًا ، مما يؤدي ببعض المستخدمين إلى قضاء ساعات في تصحيح أخطاء مطبعية صامتة تمامًا.

يشعر باقي أعضاء فريق lang بقوة أن الفصل بين التعبيرات والأنماط أمر غير مقبول ، وعلى الرغم من أنني لا أوافق ، فقد قدمنا ​​جميعًا حججنا ولا أعتقد أن البقاء في طريق مسدود إلى الأبد أمر صحي.

ssokolow آسف ، ما زلت لا أتفق معك. يمكن للمترجم أن يحذرك من هذا النوع من الأخطاء المطبعية ، ولكن ماذا لو كتبت "x = 5" حيث يجب أن يكون "x = 6"؟

المترجم ليس هو الأفضل لتجنب الأخطاء المطبعية ، فالمبرمج هو.

إذا لم يكن لهذا التغيير أي آثار جانبية ، فأنا أتفق تمامًا. لكن هذا يترك اللغة تفقد الطلاقة الجمالية والكتابة والقراءة ، وهو أمر لا يستحق فقط في رأيي الشخصي.

يواجه صدأ اليوم بالفعل مشكلة في القراءة والكتابة ، وكلما كانت البنية غير الشائعة والمضادة للحدس ، كلما زاد منحنى التعلم ، لا تجعلها لغة بيرل أخرى.

withoutboats نحن نتجادل معها ، لأننا نحبها. ربما تكون هذه الحجة قد فات الأوان ، ولا يمكنها تغيير أي شيء ، فقط ...

تضمين التغريدة

هناك بالتأكيد مقايضات يجب إجراؤها ، لكن لدي انطباع بأننا لن نتفق أبدًا على أفضل نقطة توازن بينهما.

بغض النظر عن الذوق الشخصي ، أرى ..= ثمنًا زهيدًا يجب دفعه لتجنب ما قد يكون قدرًا كبيرًا جدًا من الوقت الضائع في محاولة تعقب الأخطاء.

(مجال تركيزي هو تصميم UI / UX وأحد أكبر القواعد التي يعلمونك إياها هي أنه يجب أن تهدف إلى تسهيل ارتكاب خطأ يتناسب عكسياً مع الضرر و / أو الوقت اللازم لإصلاحه. )

في رأيي الصغير ، 5 مقابل 6 أكثر وضوحًا من .. مقابل ... .

zengsai أستقبل رسائل بريد إلكتروني كثيرة جدًا من أجل هذه المحادثة فقط ،

daiheitan هذا اتصال عادي. إذا لم يعجبك ، أقترح عليك إلغاء

عندما نظرت إلى Rust لأول مرة ، فوجئت حقًا بصيغة .. . (1..10).sum() هو ... مجموع الأعداد الصحيحة من 1 إلى 9؟ إذا قدمت هذا النحو إلى الوافد الجديد وسألته عما تعنيه ، فمن المحتمل جدًا أنه سيتوقع أن ينتقل من 1 إلى 10. وسيكون محقًا في فعل ذلك ، لأنك تتوقع أن تعبر البنية المتماثلة عن التماثل نطاقات. لماذا يجب تضمين 1 وليس الـ 10؟

إضافة نموذج آخر غير متماثل ..= لنطاق متماثل يجعل هذا أكثر تناسقًا بصريًا. قد يتساءل المرء لماذا لا يحتاج الجانب الأيسر إلى = ليكون شاملاً ، لذلك سيكون =..= للنطاقات الشاملة على كلا الجانبين.

شيء مثل بناء جملة Swift ( ..< للحصري و ... للضمين) من شأنه تجنب هذه المشاكل وتحسين قابلية القراءة. يمكنك بسهولة تخمين المعنى بشكل صحيح حتى لو كنت جديدًا تمامًا على اللغة ، لذلك لا يوجد شيء واحد يجب تذكره. كنت أتوقع أن يتم اختيار شيء من هذا القبيل ، لا سيما بالنظر إلى دفع روست نحو صداقة الوافدين الجدد.

rkarp إلى حد ما ، ربما

على سبيل المثال ، هناك الكثير من تأثير Python في Rust وتستخدم Python نفس النوع من النطاقات نصف المفتوحة. (على سبيل المثال ، لدى Python range(1, 5) أو myList[1:5] كلاهما نفس سلوك Rust 1..5 )

كان تبرير ذلك في Python مرتبطًا بوجود بناء جملة واحد فقط ، كما أن وجود بناء جملة نصف مفتوح جعل من السهل القيام بأشياء مثل head, tail = myList[:pivot], mylist[pivot:] .

ومع ذلك ، نظرًا لأن Rust قد تجاوز 1.0 ، فهناك قواعد صارمة إلى حد ما حول عدم كسر الكود الحالي. يجب أن يظل .. للحصري خارج الأنماط و ... للأنماط الداخلية الحصرية صالحًا.

..= يعمل لأنه يمكنك قبول .. (حصري) و ..= (شامل) في كل مكان والتعامل مع ... كمرادف مهمل لـ .. في الأنماط.

مجرد قول ، وجود ..= كرمز هو تغيير غير متوافق تقنيًا ، لأنه يؤثر على قواعد :tt في وحدات الماكرو. ربما لن تكون مشكلة ، ولكن قد ترغب في التحقق للتأكد مما إذا كان شخص ما لا يفعل ذلك ، معتبرا أنه قد يكون تغييرًا هادئًا أيضًا. (البديل هو السماح .. /* why not */ = ، والتي لا أعتقد أنها فكرة جيدة)

ssokolow من الناحية الفنية ، إنه خطأ في النوع Rust ، وليس خطأ في التحليل. a = 2 هو تعبير يُرجع () ، و if يتوقع bool ، لذلك من الواضح أنهما غير متوافقين.

القواعد تتغير ببطء. من الناحية الفنية ، ..= عبارة عن 3 رموز مميزة حيث لا توجد مساحة بعد أول 2.

eddyb : أنا أعترف ، لا أفهمها تمامًا. هل هناك طريقة لتقديم رمز جديد دون التأثير على كيفية تحليله؟

يُبلغ هذا الرمز حاليًا عن "القاعدة 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

تضمين التغريدة
بعد أن قدمنا ..= كمعامل واحد ، سيكون الخطأ:

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 5.. = x ويجب تجميعه: if let (single expression) لا معنى له ، لذلك لا أعتقد أن هناك أي غموض.

@ kennytm لذلك أظهر كلانا

daboross كما قال kennytm ، 5.. ليس نمطًا ولا يتم تجميعه ، حتى الآن. ولن يتغير هذا إذا أضفنا ..= كمعامل. لا يوجد غموض. الشيء المهم هو أنه الآن ، لا يمكن تحليل ..= كمعامل واحد ولكن بمجرد أن نتمكن من تحليله كعامل واحد ، فلا يوجد أي غموض.

5.. ليس نمطًا صالحًا حاليًا ، كما أنه ليس لدينا أنماط فواصل نصف مغلقة. ومع ذلك ، فإن الافتقار إلى أنماط الفترات نصف المغلقة هو أمر يُنظر إليه غالبًا على أنه مصدر عدم تناسق عند مقارنته بتعبيرات النطاق وقد ينتهي به الأمر إلى أن يتم تنفيذه للأنماط أيضًا. قد نرغب أيضًا في إضافة القدرة على حذف جانب واحد من الفاصل الزمني في الأنماط لاحقًا لمطابقات عدد صحيح شامل على سبيل المثال.

لذا في حين أن ملاحظة @ clarcharr لا تشير بالضرورة إلى الغموض عند النظر في القواعد الحالية ، فمن المؤكد أنها غموض عند النظر في التوسعات المستقبلية المحتملة التي قد تتعارض مع اقتراح استخدام ..= للأنماط.

مع أخذ ذلك في الاعتبار أود أن أقترح استخدام بعض الرموز الأخرى هنا. ^ مناسب تمامًا بالنسبة لي ، حيث يتم استخدامه فقط في سياق تعبير حاليًا IIRC.

(هذا سبب آخر يجعلني أعتقد أنه من الجيد التحرك لتثبيت البنية الآن ، وبناء الجملة لاحقًا.)

nagisa ليس هناك تعارض بخصوص if let إذا تمت إضافة الرمز المميز ..= قبل دعم نمط RangeFrom. يمكن للمرء إضافة مسافة بين .. و = لإزالة الغموض ، تمامًا مثل x <- y (موضع في) مقابل x < -y (أقل من + سلبي).

(نظرًا لأن ^ هو المشغل الحصري أو المشغل أجد أنه من السخرية استخدام ..^ للنطاق الشامل )

في آلاف النطاقات التي كتبتها ، عدد قليل منها مغلق تمامًا ، ربما حتى واحد أو اثنين نصف مفتوح بطريقة خاطئة ، ما زلت لا أرى حقًا الحاجة إلى أي بناء جملة إضافي. ليس من الصعب الكتابة 1..(n+1) .

هذا لا يعمل مع end = T :: max_value ().

في 29 مايو 2017 ، الساعة 16:33 ، كتب "Diggory Hardy" [email protected] :

في آلاف النطاقات التي كتبتها ، تم إغلاق عدد قليل منها تمامًا ،
ربما حتى نصف مفتوح بطريقة خاطئة ، ما زلت لا أفعل ذلك حقًا
انظر إلى الحاجة إلى أي بناء جملة إضافي. 1 .. (ن + 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 ، كتب " Simonas Kazlauskas "

هذا لا يعمل مع end = T :: max_value ().

في 29 مايو 2017 ، الساعة 16:33 ، كتب "Diggory Hardy" [email protected] :

في آلاف النطاقات التي كتبتها ، عدد قليل منها كامل
مغلق ، ربما حتى نصف مفتوح بطريقة خاطئة ، ما زلت لا
نرى حقًا الحاجة إلى أي بناء جملة إضافي. 1 .. (ن + 1) ليس بهذه الصعوبة
اكتب.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/rust-lang/rust/issues/28237#issuecomment-304662258 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AApc0ipynL_qrZqUBldOJOX046RNY2H_ks5r-skwgaJpZM4F4LbW
.

أتمنى حقًا أن نثبت السمات والأنواع بالفعل باستخدام طريقة لتكوينها لأنني متأكد تمامًا من عدم وجود خلاف حول ذلك. من فضلك لا تدع ركوب الدراجات فوق بناء الجملة يعيق استقرار الوظيفة الأساسية نفسها.

هذا لا يعمل مع end = T :: 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-Motar عبر بعض كود الحالة الخاصة إذا لزم الأمر ؛ على أي حال ، أعتقد أنه لا يمكن تجنب هذا النوع من المشاكل إلا باستخدام ... .
  
  

قبل تثبيت النطاقات الشاملة ، يجب أيضًا إصلاح المشكلة رقم 42401 imo ، حيث سيكون الإصلاح بمثابة تغيير فاصل بعد التثبيت.

@ 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
            }
        }
    [...]

إزالة

تحديث مربع اختيار آخر: PR https://github.com/rust-lang/rust/pull/42134 طبق https://github.com/rust-lang/rfcs/pull/1980 قرص

Bump: بأي طريقة يمكننا من خلالها تثبيت الهياكل على الأقل لـ 1.20؟

ماذا عن استعارة عامل الانتقال الشهير من C ++ لبناء جملة النطاق الشامل؟ 😛

nikomatsakis و @ rust-lang / libs (لا أعرف كيف أضع علامة على هذا) ، كيف ستشعر إذا

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 و .. هي تركيبات صالحة في Rust ، لا يزال هذا ينتج بعض الغموض في العمليات الحسابية: /

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 . هذه بالطبع ، تفعل الشيء نفسه ، وتسمح للأشخاص باستخدام أساليب بناء جملة مختلفة. هذا شيء جيد إذا سألتني!

للإضافة إلى ذلك ، فإن الترميز ..= يتوافق مع الرموز <= و >= (والتي تعتبر أيضًا _ شاملة_).

من الجيد دائمًا التحقق من الاحتمالات الأخرى الموجودة ، ولكن ربما لا يكون هذا هو الحل الصحيح.

يوافق. عند المقارنة بـ <= و >= ، يبدو ..= معقولًا ، بل منطقيًا.

بالمناسبة ، إذا كنت من محبي ... أو كنت لا تحب مظهر ..= ، فسيكون الحل الوسط هو استخدام بعض الخطوط مع وصلات البرمجة ، مثل ..= ، والذي قد يتم تعيينه إلى ... ، أو حتى شيء غريب ، مثل ⩷ أو ⩦ أو ≔.

كسر التغيير في جميع رموز الصدأ الحالية باستخدام نطاقات ... ميت عند الوصول ،
آسف. إذا كان لدى شخص ما اقتراحًا جادًا متوافقًا مع الإصدارات السابقة لـ
معالجة المخاوف التي تم طرحها ولم تتم مناقشتها
بالفعل ، دعنا نسمعها ، لكن دعنا على الأقل نحافظ على ذلك كمعيار ، نعم؟
هذا الخيط مليء بمظلات الدراجات وقد اتخذ الفريق بالفعل قرارًا بذلك
هذا هو شريط عال للتوضيح.

على أي حال ، يبدو أنه لا يزال هناك الكثير من الدراجات التي تدور حول البنية الفعلية. لقد قدمت # 43086 لتحقيق الاستقرار على الأقل في الهياكل والسمات والإشارات بحيث يمكن استخدام الوظيفة الأساسية (يبدو أن هناك طلبًا ، انظر التعليق من @ retep998 أعلاه).

الفيل في الغرفة هو أن .. هو في الواقع المشكلة الحقيقية هنا بسبب شكله المتماثل ولكن معناه غير المتماثل. ربما يستلزم "الشيء الصحيح الذي يجب فعله" إهماله ، ولكن لا توجد إرادة للقيام بذلك لأن الكثير من التعليمات البرمجية تستخدمه بالفعل.

يعد التقليل من قيمة ... المتسق تمامًا (المظهر المتماثل ، المعنى المتماثل) هو الحل السهل ، ولكن على حساب إضافة عامل تشغيل آخر غير متسق في ..= . يبدو أن إضافة تصميم سيئ للتغلب على التصميم السيئ السابق.

هناك مشكلة أخرى في هذا بسبب هذا التناقض المزدوج: لا توجد طريقة جيدة لإضافة آخر متغيرين متبقيين للشمول (حصري على كلا الجانبين وحصري على الجانب الأيسر فقط). نظرًا لأن كلا من .. و ..= سيكون لهما بالفعل = ضمنيًا على الجانب الأيسر ، فسنضطر إلى رفض ذلك بطريقة ما ، ربما باستخدام < . لذلك يجب أن يبدوا مثل هذا:

• <..= مقابل (a; b]
• <.. مقابل (a; b)

حظًا سعيدًا في التخمين الصحيح لما تعنيه هذه الأشياء كوافد جديد. لذلك ربما (بحق) لن يتم اعتبارهم مضافين أبدًا.

إذا لم يكن .. مترسخًا أو لم يكن موجودًا حتى ، فإن الخروج بتصميم متسق لكل هذا من نقطة الصفر لا يبدو صعبًا للغاية ، على سبيل المثال:

• .. (أو ... ) مقابل [a; b]
• ..< مقابل [a; b)
• <.. مقابل (a; b]
• <..< مقابل (a; b)

لدي شعور بأن الخيارين الأخيرين قد يكونان مفيدان في مرحلة ما ، فهل يجب علينا حقًا قطع الطريق نحوهما بهذه السرعة؟ على أي حال ، فإن السبب الوحيد الجيد لاختيار ..= على إهمال .. هو كسر كود أقل من ذلك بكثير ، لكنه سيكون في أحسن الأحوال شرًا ضروريًا ، لا شيء يجب الاحتفال به.

_تعديل: تم إضافة مثال وبعض التعليقات لمزيد من الوضوح.

أتفق مع rkarp على أن .. هي المشكلة الفعلية هنا ، وليست ... أو ..= . المعنى غير المتماثل سيء بشكل خاص بالنظر إلى أن اللغات الأخرى (الأكثر شيوعًا) تقوم في الواقع بتعيين معنى متماثل لها. يعتبر كل من Kotlin و Ruby و Haskell أن الرقم 5 يقع في النطاق 3..5 على سبيل المثال. يبدو أن الأوراق الرياضية تفضل ذلك أيضًا. أسوأ شيء هنا هو أن المبتدئين ليس لديهم فرصة لتخمين سلوك 3..5 في Rust: إما أن تقرر أن 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 هذه ليست فكرة جديدة ولا يمكننا استخدامها لأسباب ذكرناها بالفعل.

أتفق تمامًا مع فكرة أننا إذا كنا نصمم اللغة من البداية مع الاستفادة من الإدراك المتأخر ، فإننا نرغب في النظر في تركيب النطاقات الحصرية والشاملة معًا. أعتقد أن ..= ليس المشغل المثالي لنطاق شامل ؛ إنه ببساطة الخيار الأفضل حاليًا على الطاولة. لكن إهمال مشغل النطاق الحصري الحالي سيكون مؤلمًا للغاية ، وسيؤثر على مستخدمي ومشاريع Rust الحالية.

هناك العديد من المقترحات الأخرى التي يمكن أن تنجح. على سبيل المثال ، لم أشاهد اقتراح ..@ و x..@y يبدو مثيرًا للذكريات. التحدي هو العثور على شيء أكثر إقناعًا من الاقتراح الحالي ، مع الاحتفاظ بنقص الغموض.

كنت أرغب في إبراز تعليق 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 ميت عند وصول مقترحات النحو قد قدمت منذ أن اتخذ فريق اللغة قرارهم. الوافدين الجدد يرجى قراءة الموضوع. كانت لدينا أسباب وجيهة للغاية لاتخاذ القرارات التي وعدنا بها.

يجب تحديث IMHO ، OP للإشارة إلى أنه لا ينبغي إجراء المزيد من المناقشة النحوية في هذا الموضوع ، ويجب نقل أي مقترحات لبناء جملة النطاق الحصري (على سبيل المثال (أ ، ب) و (أ ، ب] نطاقات) إلى موضوع آخر.

يجب أن يتحدث هذا فقط عن الأشياء التي يجب القيام بها لتحقيق الاستقرار في الخطة الحالية.

clarcharr لقد اتخذت قرارًا فرديًا في الغالب

مرحبًا ، أنا جديد وأود أن أبدأ العمل على هذا. سأحاول كتابة PR لإضافة ..= كمرادف لأنماط ... ، وإيقاف ... في التعبيرات ، وعرض خطأ يفيد بأنه تم تغيير بناء الجملة إلى ..= . هل هذا الصوت صحيح؟

@ Badel2 رائع. لقد بدأت بالفعل - سأدفع فرعي قريبًا وأربطه هنا.

durka فقط للتوضيح - هل تعرض السماح لـ @ Badel2 بالمضي قدمًا بدءًا من فرعك؟ هل يمكنك إرشادهم كجزء من عمل الفترة الضمنية؟ إنهم في قناة Gitter.

أوافق أيضًا على أن المشكلة الفعلية هي .. . لذا ، فإن الحل الأكثر ملاءمة هو إهمال (وليس الاستبدال مرة واحدة ، لذا لن __ لا _ يكسر الكود الحالي) .. لصالح شيء مثل ..< (لن يكون هناك التباس بين a..<b و (a..)<b ، لأن .. سيتوقف في النهاية عن الوجود).

@ hyst329 يرجى قراءة المشاركات التي تم إجراؤها بالفعل.

تقول المشاركة الأولى ، بخط غامق ، "لا ينبغي إجراء مزيد من المناقشة النحوية في هذا الموضوع."

وبغض النظر عن ذلك ، فإن ما تصفه قد تم اقتراحه هنا عدة مرات من قبل أشخاص آخرين لم يقرأوا المناقشة الحالية وهناك أسباب متعددة تم تقديمها رداً على سبب عدم كونها خيارًا قابلاً للتطبيق.

عذرًا ، هذا ليس بنّاءً للغاية ، لكن في كل مرة أرى فيها ..= وأحاول أن أتذكر ما هو ، يبدو وكأنه عامل إسناد مشابه لـ += أو <<= . إنه شعور محير للغاية أنه ليس كذلك. (على الرغم من أنه من المسلم به أن هذا كان خارج السياق ، على سبيل المثال "الدعم الأولي لـ ..= syntax" 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>) في التعبيرات التي تتطلبها بالفعل. إنه أكثر تفصيلاً ولكن يسهل فهمه.

تضمين التغريدة

... وكنت مقتنعًا بأن ... لا يمكن الدفاع عنه في الأوقات التي تم إنقاذي فيها من خطأ خفي بواسطة رسالة المترجم "لا يمكنك استخدام بنية النطاق الشامل على ثابت".

من السهل جدًا أن تضرب عن طريق الخطأ . مرة واحدة (أو ، نظرًا للميكانيكا المستخدمة ، مرة واحدة قليلة جدًا) عندما تضغط عدة مرات في تتابع سريع.

لقد راجعت قبالة "تغيير لقبول ..= كمرادف ل ... في أنماط وقبول ..= في التعبيرات" لأنه هو الحال بالفعل بعد # 44709 مع ميزات dotdoteq_in_patterns و inclusive_range_syntax على التوالي. ما تبقى هو مجرد توثيق وتثبيت.

طلب التثبيت

أرغب في تثبيت النطاق الشامل عند 1.26 (بيتا في 30 مارس ، ومستقر في 11 مايو) أو قبل ذلك. تم تقديم العلاقات العامة الخاصة بالاستقرار كـ # 47813.

ملخص

سيتم تثبيت الميزات الثلاث التالية:

• 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);
  

توثيق

يتم تقديم العديد من وثائق العلاقات العامة من خلال

• الكتاب: 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 في حلقة for-loop ، كمكرر ، كمؤشر شريحة ، وأولوية عامل التشغيل ..= ، وسلوك فحص النوع.
• 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 عند استخدام طرق المكرر بدلاً من حلقة for-loop.

  قد نحتاج إلى إبقاء حقول RangeInclusive غير مستقرة إذا لم نرغب في الالتزام بالتصميم في rust-lang / rfcs # 1980 حتى الآن.

قد نحتاج إلى إبقاء حقول RangeInclusive غير مستقرة إذا لم نرغب في الالتزام بالتصميم في rust-lang / rfcs # 1980 حتى الآن.

+1
هل هناك حاجة لفضح حقول النطاق مباشرة ، وليس من خلال بعض الواجهات القائمة على الأسلوب؟

تضمينrfcbot fcp

وفقًا لملخص @ kennytm ، أقترح أن نحقق الاستقرار في بناء جملة النطاق الشامل ( ..= ).

(ومع ذلك ، أجد أن الأداء المنخفض البالغ ..= مثير للقلق بشكل معتدل ، وأتساءل عما إذا كان من المنطقي جعل ..= لم يتم تنفيذه بشكل مباشر Iterator في الوقت الحالي ، في من أجل التخفيف من هذا.)

اقترح عضو الفريق nikomatsakis دمج هذا. الخطوة التالية هي المراجعة بواسطة باقي الفرق الموسومة:

• [x] @ بورنتسوشي
• [x] Kimundi
• [] @ كودراوس
• [x]alexcrichton
• [x]aturon
• [x]cramertj
• [x] dtolnay
• [x]eddyb
• [x]nikomatsakis
• [x]nrc
• [x]pnkfelix
• [x]sfackler
• [] @ بدون قوارب

لا مخاوف مدرجة حاليا.

بمجرد موافقة غالبية المراجعين (وعدم اعتراضهم على ذلك) ، سيدخل هذا فترة التعليق النهائية. إذا اكتشفت مشكلة كبيرة لم تُثار في أي وقت في هذه العملية ، فيرجى التحدث!

راجع هذا المستند للحصول على معلومات حول الأوامر التي يمكن أن يقدمها لي أعضاء الفريق.

أتساءل عما إذا كان من المنطقي أن نجعل .. = لم يتم تطبيق Iterator بشكل مباشر في الوقت الحالي ، من أجل التخفيف من ذلك.

يتم تنفيذ هذه السمات المستقرة مقابل RangeInclusive<T> على الأقل لبعض T s في الليلة الحالية: Iterator ، FusedIterator ، ExactSizeIterator ، Debug ، Clone ، Eq ، PartialEq ، Hash ، TrustedLen .

SimonSapin نسيت ، هل

ومع ذلك ، أعتقد أيضًا حقًا أن 1..2 و 1..=2 يجب أن يكونا قابلين للاستخدام في جميع الأماكن نفسها ، مما يعارض إجراء أي تغييرات هنا ، وبدلاً من ذلك يقترح علينا متابعة التخفيف وتحسين تحسينات.

لماذا لا نطاقات الحالات الخاصة حيث end == MAX ؟ قد يؤدي ذلك إلى وجود نطاقات أكثر شمولاً لها نفس الكود مثل النطاقات الحصرية ، باستثناء تلك التي تذهب مباشرة إلى الحد لديها المزيد من التعليمات البرمجية. نظرًا لأن الفرع end != Max لن يقوم أبدًا بتعديل end ، فيمكن بسهولة تضمينه بواسطة المُحسِّن.

nikomatsakis لا ، الهياكل غير مستقرة في الوقت الحالي. لكن اقتراح @ kennytm يتضمن استقرارها.

تضمين التغريدة

لا ، الهياكل غير مستقرة في الوقت الحالي. لكن اقتراح @ kennytm يتضمن استقرارها.

أرى؛ في الواقع ، هذا هو السبب في أنني ذكرت أنه سيتعين علينا إزالة Iterator الضمني الآن أو أبدًا. =)

SimonSapin لا أعتقد أنه يمكننا تثبيت صيغة التعبير a..=b بدون تثبيت البنية. ومع ذلك يمكننا ترك الحقول غير مستقرة ، إذا اعتقدنا أننا قد نغيرها.

حسنًا ، لم أقصد أن أقول إننا لا يجب أن نثبت الأنواع عند تثبيت بناء الجملة لبناء قيم من هذه الأنواع.

هزة للهروب من بنية النطاق وركوب الدراجات وتحقيق الاستقرار! : تادا:

بالنظر إلى آلة الزمن ، سأجادل في عدم وجود أي من أنواع النطاق التي تكون :Iterator ، وأنهم فقط :IntoIterator . ولكن كما هو الحال الآن ، أعتقد أن الاتساق مع Range هو الخيار الأفضل. يمكننا وضع هذه الحالة مع Chain في دلو "حسنًا ، اتضح أن التكرار الداخلي يكون أسرع في بعض الأحيان".

هناك شيء آخر لم يتم حله ، يتعلق أيضًا بالتكرار: هل نريد الالتزام بأي تمثيل معين لـ RangeInclusive بمجرد إجراء التكرار؟ في الوقت الحالي ، ينتهي الأمر عند 1..=0 ، ولكن كانت هناك خيارات أخرى تمت مناقشتها . لا أعرف ما إذا كانت الوثائق ستكون كافية لمنع الناس من الاعتماد عليها ، على الرغم من أن النطاق الحالي يجعل نطاق ما بعد التكرار عديم الفائدة تمامًا ، وهو ما يثبطه على الأقل.

يمكننا وضع هذه الحالة مع Chain في دلو "حسنًا ، اتضح أن التكرار الداخلي أسرع في بعض الأحيان".

أعتقد أننا نحتاج حقًا إلى إصلاحه حتى لا يقل الأداء عن نطاق حصري ؛ لا يوجد سبب أساسي لذلك.

ليس هناك سبب _ أساسي_ لوجود ذلك.

يعتمد ذلك على الثوابت التي يمكننا فرضها. في الصيغتين السابقتين مع جزء إضافي من الحالة ، لم يكن هناك شيء يفرض أن هذا الجزء تم تعيينه بالفعل عندما انتهينا من التكرار (وفي الحقيقة لم يتم تعيينه على قيم حرفية مثل 100..=0 ) ، لذا فإن الحلقة يجب أن تكون حالة الخروج مركبة ، مما يعني أن LLVM لم تعد مستعدة لفكها لنا ، لذلك نحصل على أداء أسوأ. الإصلاح الكامل الذي يبدو أنه يعني إما جعل البنية أكبر وعدم وجود حقول حانة ، أو جعل RangeInclusive: !Iterator ، أو جعل LLVM أفضل في تحسين هذه الأنواع من الحلقات.

بعد قولي هذا ، لقد جربت بعض الطرق المختلفة لكتابة RangeInclusive::next ، ويبدو أن اختيار نفسي في الماضي لمطابقة Option<Ordering> يجعل LLVM حزينًا للغاية - فقط وضع عوامل المقارنة هناك بدلاً من ذلك يعطي تجميع أفضل بكثير. تحرير العلاقات العامة: https://github.com/rust-lang/rust/pull/48057

بالنظر إلى آلة الزمن ، سأجادل في عدم وجود أي من أنواع النطاق: Iterator ، وأنهم مجرد: IntoIterator. ولكن كما هو الحال الآن ، أعتقد أن الاتساق مع Range هو الخيار الأفضل. يمكننا وضع هذه الحالة مع Chain في دلو "حسنًا ، اتضح أن التكرار الداخلي أسرع في بعض الأحيان".

أنا أتفق مع هذا بشكل أساسي.

: bell: هذا يدخل الآن فترة التعليق النهائية ، وفقًا للمراجعة أعلاه . :جرس:

: bell: هذا يدخل الآن فترة التعليق النهائية ، وفقًا للمراجعة أعلاه . :جرس:

rfcbot fcp إلغاء

withoutboats و KodrAus لم

تم إلغاء اقتراح

تضمينrfcbot fcp

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

اقترح عضو الفريق cramertj دمج هذا. الخطوة التالية هي المراجعة بواسطة باقي الفرق الموسومة:

• [x]alexcrichton
• [x]aturon
• [x]cramertj
• [x] dtolnay
• [x]eddyb
• [x]nikomatsakis
• [x]nrc
• [x]pnkfelix
• [x]sfackler
• [] @ بدون قوارب

لا مخاوف مدرجة حاليا.

بمجرد موافقة غالبية المراجعين (وعدم اعتراضهم على ذلك) ، سيدخل هذا فترة التعليق النهائية. إذا اكتشفت مشكلة كبيرة لم تُثار في أي وقت في هذه العملية ، فيرجى التحدث!

راجع هذا المستند للحصول على معلومات حول الأوامر التي يمكن أن يقدمها لي أعضاء الفريق.

: bell: هذا يدخل الآن فترة التعليق النهائية ، وفقًا للمراجعة أعلاه . :جرس:

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 بسرعة كبيرة

أنا شخصياً سأكون على ما يرام إذا كنت أريد أن أكون "مستقرة إنستا"

تم تثبيت inclusive range حيث تم دمج طلب السحب # 47813 ولكنه ليس في الإصدار 1.25 ، لماذا؟ على الرغم من دمج طلب السحب في 16 مارس

لا تتوفر ميزة mominul إلا بعد دمجها في الفرع الرئيسي ، وبالتالي يتوفر ..= بدءًا من 1.26 وليس 1.25.

وبهذه الطريقة يمكنك اختبارها على الإصدار التجريبي وكل ليلة قبل دفعها إلى الاستقرار.

شكرا على المدخلات @ kennytm و clarcharr ! إصدار Rust 1.26 ليس مملًا بالتأكيد على الأقل بالنسبة لي! :ابتسامة:

أعلم أن الأوان قد فات للمشاركة في هذه المناقشة ، ولكن لماذا لا تحذف بناء الجملة .. بالكامل وتستخدم الكلمات بدلاً من ذلك؟

في Scala ، لديك 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 ككلمات رئيسية لدعم ذلك ، وسيكون هذا تغييرًا أكبر بكثير.

إنه يعمل بشكل جيد في Scala ، لكن خيارات تصميم Rust تختلف إلى حد كبير.

ElectricCoffee على الرغم من

أعتقد أنه يجب الاحتفاظ بالكلمات الرئيسية للغة المضمنة عند الحد الأدنى ، حيث قد تتعارض مع أسماء الوظائف أو المتغيرات.

على الرغم من أن to و until ليست كلمات مستخدمة في std (على حد علمي) ، أنا متأكد من أنها كلمات شائعة تستخدم في الصناديق الأخرى و المشاريع.

daboross هذه في الواقع نقطة عادلة لم a .. b بمعنى a to b ، بغض النظر عن a و b الواقع.

ونعم ، timvisee ربما هم كذلك.

ElectricCoffee ولكن إذا كان to يعني ..= و until يعني .. فعليك كتابة a until b ، وليس a to b بدلاً من a .. b . كما ترى ، ليس استخدام هذه الكلمات "أكثر" من المعاملين بديهيًا .. ولكن سيكون من الأسهل كتابة until كل مكان يتم فيه استخدام .. ، لأنه أكثر شيوعًا من ..= (لذا إذا تم استخدام الكلمات ، يجب تخصيص الكلمة الأقصر لـ .. ).

وأنت محق تمامًا بشأن Boscop ، فقد كان مجرد مثال على كيفية عمل الكلمات.

أعتقد أنني رأيت to للحصري و upto للتضمين في بعض اللغات أيضًا.
كان المقصود كله كفكرة.

في Scala ، يتم استخدام النطاق الشامل أكثر من النطاق الحصري ، وبالتالي يتم إعطاء الكلمة الأقصر.

timvisee واحدة ببساطة لا يمكن استخدام a.to(b) و a.until(b) ، هناك حاجة إلى أي كلمات أخرى (وهذا لا يجعل بناء الجملة أكثر من ذلك بكثير أخرق).

@ hyst329 لم أفكر في ذلك حتى. يجب أن أقول ، أنا حقًا أحب هذه الفكرة! أنت محق بالفعل.

لا أعتقد أن هذا سيكون بديلاً كاملاً مناسبًا للصيغة الحالية (/ الجديدة). لكنها ستكون إضافة لطيفة.

يجب أن أتفق مع تعليق Boscop حول الحدس. بصرف النظر عن كلمات مثل "بما في ذلك" و "باستثناء" ، فإن اللغة الإنجليزية اليومية لا تميز حقًا بين النطاقات الشاملة والحصرية بقوة كافية ليكون هناك اختصار جاهز.

ما لم يتم استخدامه في سياق يتم فيه استخدام "أ إلى ب" أيضًا ، فمن الغموض ما إذا كان "أ إلى ب" يعني نطاقًا شاملاً أو حصريًا في الكلام اليومي هنا في جنوب أونتاريو ، كندا ، و "حتى" مرتبط مع مرور الوقت بقوة كافية ، عند استخدامها بهذا المعنى الأكثر مرونة ، فمن غير الواضح ما إذا كان "الحدث" الذي "حتى" يرتبط به "حتى نرى X" أو "حتى نقوم بمعالجة X".

@ hyst329 سيؤدي استخدامها كطرق إلى تقييد النطاقات لأنواع الأرقام. أنا أفضل حقًا عدم وجود صيغة واحدة لنطاقات الأرقام وأخرى لنطاقات من الأشياء الأخرى.

أعتقد أنه يمكننا إضافة سمة جديدة شاملة إلى المقدمة لإنشاء نطاقات ، لكن هذا لا يزال على وشك تغيير جذري للأشياء التي لها طرق فعلية to و until .

أعترف ، اعتقدت أن اقتراح الكلمات الرئيسية كان نكتة كذبة أبريل.
تم تثبيت .. = بناء الجملة.

في الخميس ، 5 أبريل ، 2018 الساعة 1:53 مساءً ، كتب David Ross [email protected] :

@ 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 تعليق على هذه المسألة ، والتعليق الأول يقول:

لا ينبغي إجراء مزيد من المناقشة النحوية في هذا الموضوع . يجب أن تتم أي مقترحات مختلفة لبناء جملة النطاق الحصري في منتدى المستخدم أو المنتدى الداخلي ، بعد أن تقرأ جميع التعليقات الحالية وأسبابها المنطقية هنا. والجدير بالذكر أن كسر التوافق مع الإصدارات السابقة ليس بداية.

سأقوم بقفل هذه المشكلة الآن ، آسف إذا خطوت على أي أصابع!

أعتقد أن كل شيء تغطيه هذه القضية قد تم. يرجى إعادة فتح قائمة التحقق وتحديثها في رسالة المشكلة الأصلية إذا كان هناك شيء آخر.