Rust: إزالة عامل التشغيل الثلاثي

أنا موافق. كنت أتساءل لماذا كان لدينا عامل التشغيل الثلاثي أيضًا.

متفق. أتمنى لو جعلت JS لغة تعبير. الانقسام الكبير في العبارة / التعبير يحفز؟: لكن الصدأ خالٍ من ذلك ، وإذا كان وإلا يكفي.

/يكون

بصفتي مستخدمًا ثقيلًا جدًا لـ؟: عامل تشغيل في C / C ++ ، فأنا أفضل بناء الجملة المضغوط. أعتقد أيضًا أنه يتم تنسيقه بشكل أفضل عندما يكون التعبير طويلاً جدًا بحيث لا يتناسب مع سطر واحد:

let x = some_very_long_condational
     ? if_true
     : if_false

let x = if some_very_long_condational 
     { if_true}
     else { if_false}

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

جمعية البناء الخيرية.

انا يعجبني:

let x = if some_very_long_condational { 
                 if_true
           } else { 
                 if_false
           }

تضيف بعض الأسطر الإضافية ("سطر آخر" والقوس الأخير) ، لكنها تحافظ على نظافتها ويمكنك إضافة أكبر قدر تريده في أي منهما.

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

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

ومع ذلك ، لن أعترض بشدة إذا تمت إزالة عامل التشغيل؟:.

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

سيكون الاستخدام غير المشفر هو السماح لهم كجزء من اسم المسند.
على سبيل المثال ، "فارغ؟ ()" بدلاً من "is_empty ()".

marijnh ++ :)

أنا شخصياً لا أبالي. جادل إيغور بالعودة الثلاثية في https://mail.mozilla.org/pipermail/rust-dev/2010-November/000110.html

تم ذلك في طلب السحب # 1705.

    return parent.index_of(child_a) < offset_b ? -1 : 1

تبدو بلا حدود أفضل من

    return if parent.index_of(child_a) < offset_b {
        -1 
    } else {
        1
    }

إذا كان علينا أن نكون ثقيرين بشأن هذا ،

return -1 if parent.index_of(child_a) < offset_b else 1

سيكون أفضل بكثير.

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

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

أنا أيضا أفتقد بناء الجملة هذا

أعتقد أن هناك ثلاثة تأثيرات تآمرية في العمل هنا ، أي

1) "انقسام البيان / التعبير العظيم" (BrendanEich) ؛
2) إكراه غير المنطقيين في السياقات المنطقية ؛
3) حتى اللغات "الديناميكية" لا تحصل عادةً على "بناء جملة ديناميكي" (وحدات ماكرو حقيقية) و "دلالات ديناميكية" (مثل لغة بايثون from __future__ import division ) هذه الأيام.

(1) يعني أن if ... then ... else ... يختلف اختلافًا جوهريًا عن ... ? ... : ... ، وهو تمييز يمكن الاستغناء عنه تمامًا. هناك حالات حافة مثل return ، لكن التمييز بشكل عام ليس مطلوبًا.

(2) تعني أنه يمكنك ، في العديد من اللغات ، استخدام تعبيرات عشوائية كاختبارات ؛ يبدو هذا مناسبًا فقط طالما أنك لا تزال تستخدم لغتك الأولى ويزعجك بمجرد أن تبدأ بلغتك الثانية. كما هو موضح أعلاه في مناقشة reddit هذه ، ليس من الواضح لماذا يجب أن تشير القائمة الفارغة إلى false أو true - فقط اكتب if ( d.length == 0 ) ... وقد اكتسبت _ so_ الكثير من الوضوح!

(3) يعني أنك عالق في كل ما تقدمه لك لجنة اللغة ، ومهما كان ذلك ، فمن المحتمل أن تظل اللغة عالقة معها حتى يأتي شخص ما أو يتفرع أو يعيد كتابة قاعدة الكود ويعطيها اسمًا جديدًا. يمكن أن يكون مختلفا. قد تكون هناك لغات تسمح ، على سبيل المثال ، use 'ternary conditions'; use 'empty lists are false'; . هناك سوابق لذلك. بالطبع ، تتحدث الكثير من الأشياء ضد هذه المرونة لأنه سيتعين عليك دائمًا أن تضع في اعتبارك "علامات الانحراف" وتذكر نسخها عند نسخ البرنامج ولصقه. OTOH إذا كان بإمكان المستخدمين فقط تغيير بناء جملة اللغة والدلالات بسهولة وتعبئة مثل هذه الممارسات مسبقًا في وحدات قابلة للتثبيت ، فقد يساعد ذلك بشكل كبير في تطور اللغة.

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

caitp : ما هو الخطأ بالضبط؟

return if parent.index_of(child_a) < offset_b { -1 } else { 1 }

أو إحدى "الجمل المعانقة" الشخصية المفضلة لدي

return 
    if parent.index_of(child_a) < offset_b { -1 } 
    else                                   {  1 }

... أو استخدم المطابقة ، خاصة إذا كانت هناك شروط متعددة ...

return match parent.index_of(child_a) < offset_by {
  true  => -1,
  false => 1
}

... وبالطبع إذا كان من المحتمل إعادة استخدامها: فقط انقلها إلى وظيفة ...

return parent.is_child_before(offset_b)

انظر إلى ذلك ... لديك خيارات ... لأن _ كل شيء_ تعبير.

لم أكن أرغب مطلقًا في حفظ _ ستة أحرف_ يتطلب الأمر كتابة if {} else {} بدلاً من
() ? : ، بالإضافة إلى تسلسل الشروط الإضافية تبدو أجمل بكثير مع تعبير if-as-an-expression. (تصبح العوامل الثلاثية المتداخلة فوضوية بسرعة كبيرة).

في رأيي: عند استخدام if-as-an-expression لا أرى ضرورة لحقن الكثير من المسافات البيضاء غير الضرورية. أجد أيضًا أنه يقرأ بشكل طبيعي أكثر من عامل التشغيل الثلاثي ، ويساعد الإسهاب الإضافي في فصل الجملتين بصريًا. هذا فقط $0.02

أعتقد أنك ربما أخطأت في قراءة ما قلته (ولاحظ أن هذا كان منذ بعض الوقت)

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

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

return parent.index_of(child_a) < offset_b ? -1 : 1

ضد

return if parent.index_of(child_a) < offset_b { -1 } else { 1 }

caitp هو الثاني هنا حقا أسوأ بلا حدود من الأول؟ لا يزال Rust's if else تعبيرًا (وليس بيانًا).

افكاري هي:

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

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

مرة أخرى ، أنت تسيء فهم ما يقوله التعليق.

return if parent.index_of(child_a) < offset_b { -1 } else { 1 } يقيم الشرط كتعبير (وبالتالي يمكنه أن يكون معاملًا لـ return ).

الأقواس قبيحة ، لكن النقطة الأساسية تدور حول التعبيرات الشرطية وليس حول الأقواس. يتعلق الأمر بالقدرة على كتابة return foo.bar.baz(<conditional operand>) مقابل if (<conditional operand>) { return foo.bar.baz(1); } else { return foo.bar.baz(2); }

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

caitp hmm ما زلت غير متأكد من أنني

في الصدأ لا يزال بإمكانك القيام به

return foo.bar.baz(if cond { 42 } else { 0 })

؟ (أعلم أنك لم تكن تتحدث عن تقويم الأسنان بالمناسبة ، آسف للارتباك: smile_cat:)

في ذلك الوقت ، في ToT ، لم تكن هناك طريقة للقيام بذلك في Rust.

ليس لدي رأي قوي ، لكني أريد فقط أن أضيف أنه إذا كان من الأفضل استخدام ? و : لأشياء أخرى ، فلماذا لا تستخدم شيئًا مثل ?? و ?: بدلاً من ذلك ، على سبيل المثال cond ?? 43 ?: 0 ؟

لماذا تغير الطريقة التي اعتاد المطورون عليها لعشرات السنين؟

لو سام. 24 أكتوبر 2015 02:46 ، Kevin Atkinson [email protected] أ
écrit:

ليس لدي رأي قوي ، لكني أريد فقط أن أضيف ذلك؟ ويمكن
من الأفضل أن تستخدم لغير ذلك من الشكر لماذا لا تستخدم شيئا مثل ؟؟ و ؟:
في حين أن. لذلك ربما الشرط ؟؟ 43؟: 0.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/rust-lang/rust/issues/1698#issuecomment -150728625.

RenaudParis عذرًا ، ما قصدته هو: ليس لدي رأي قوي ، لكني أريد فقط أن أضيف أنه إذا كان من الأفضل استخدام ? و : لأشياء أخرى ، فلماذا لا تستخدم شيئًا مثل ?? و ?: بدلاً من ذلك ، على سبيل المثال cond ?? 43 ?: 0 ؟

أحد أسباب إزالة عامل التشغيل الثلاثي هو أن "؟" يمكن استخدامها لشيء آخر في المستقبل. كان اقتراحي هو استخدام مشغل آخر. cond ?? 43 ?: 0 أقصر من if cond {43} else {0} .

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

على سبيل المثال

if i ==0 
     return i
else 
      1  

او حتى

if i == 0  return i
    else 1  

هذا التنسيق أفضل من

 if i == 0   ? return i
      : 1  

أو

if i == 0   
      ? return i 
      : 1  

آيات

if i ==0 {
      return i
}
else {
    1
}      

قبيحة جدًا / يصعب قراءتها عن شيء شائع جدًا.

يزداد الأمر سوءًا ولكن يسهل قراءته إذا كان لديك سياسة مطورة ضد تقويم الأسنان المصري.

if i ==0
{
     return i
}
else
{
     1
 }