Rust: Удалить тернарный оператор

Я согласен. Мне было интересно, почему у нас тоже был тернарный оператор.

Согласовано. Хотел бы я сделать JS языком выражений. Отличное разделение утверждения / выражения мотивирует?: Но в Rust это отсутствует, и достаточно if-else.

/быть

Как очень интенсивный пользователь оператора?: В 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
           }

Он добавляет несколько дополнительных строк («строка else» и последняя скобка), но сохраняет его в чистоте, и вы можете добавить столько кода, сколько захотите.

Я часто использую тернарный оператор в C ++, но считаю, что синтаксис плох. Вы рассчитываете? и: посреди моря других токенов, чтобы убедиться, что это даже условно. С выражением - если у вас есть ведущий токен, указывающий читателю «здесь идет условное».

Что ж, я по-прежнему предпочитаю синтаксис оператора ?: . Я считаю, что ваш выбор форматирования слишком подробен, особенно для простых случаев, когда if_true и if_false являются одним выражением (в отличие от нескольких операторов, заканчивающихся выражением).

Тем не менее, я не буду сильно возражать, если оператор?: Будет удален.

Я также использую ?: повсюду, но я все еще думаю, что его удаление было бы хорошей идеей - это освобождает два (!) Символа ASCII в нашем синтаксисе выражения. Подумайте обо всех других ужасно загадочных вещах, которые мы могли бы с ними сделать.

Не загадочным образом можно было бы разрешить их как часть имени предиката.
Например, «empty? ()» Вместо «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) Даже «динамические» языки обычно не получают «динамический синтаксис» (настоящие макросы) и «динамическую семантику» (а-ля Python from __future__ import division ) в наши дни.

(1) означает, что if ... then ... else ... принципиально отличается от ... ? ... : ... , что является совершенно необязательным отличием. Есть крайние случаи, такие как return , но в целом различать не нужно.

(2) означает, что на многих языках вы можете использовать произвольные выражения в качестве тестов; это выглядит удобно только до тех пор, пока вы все еще используете свой первый язык, и становится раздражающим, как только вы начинаете со второго. Как указывалось выше при обсуждении на false или true просто напишите if ( d.length == 0 ) ... и вы получите _так_ много ясности!

(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)

Посмотри на это ... у тебя есть варианты ... потому что _everything_ - это выражение.

Никогда в ржавчине я не хотел сэкономить _шесть символов_, необходимых для написания if {} else {} вместо
() ? : плюс объединение дополнительных условий выглядит намного лучше с if-as-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 второй тут действительно бесконечно хуже первого? If else в Rust по-прежнему является выражением (а не утверждением).

Мои мысли:

• Второе кажется более читаемым для тех, кто не знает других языков и
• Нам, вероятно, было бы лучше оставить синтаксис ? в рукаве для будущего сахара (возможно, связанного с Option и т. Д.)

@mitchmindtree полностью.

Опять же, вы неправильно понимаете, о чем говорилось в комментарии.

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 хм, я все еще не уверена, что

В ржавчине все еще можно делать

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

? (Я знаю, что вы, кстати, не говорили о фигурных скобках, извините за путаницу: smile_cat:)

В то время в ToT не было возможности сделать это в Rust.

У меня нет твердого мнения, но я просто хочу добавить, что если ? и : лучше использовать для других целей, почему бы не использовать что-то вроде ?? и ?: , например cond ?? 43 ?: 0 ?

Зачем менять то, к чему девелоперы привыкли десятки лет?

Le sam. 24 окт. 2015 02:46, Кевин Аткинсон [email protected] a
é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
 }