Там же наверняка использование || вместо or дало бы ожидаемый результат.

P.S.: Как и оказалось.

Тернарный оператор затрудняет как чтение, так и парсинг кода, приводит к таким ошибкам.

НОРМАЛЬНО ПРИМЕНЯЕМЫЙ тернарный оператор — ни разу.

У словесной логики приоритет ниже плинтуса, да. Но тут как с паяльником, пару раз схватишься за радиатор, а через 2365 дней без травм можешь называть себя профессионалом.

Программисты вообще интересный народ, доки дали, туториалы дали, факи дали, ратионале дали. Нет, буду ныть о том, за что в физической инженерии мозги по всему цеху раскидает и старого петровича заставит махнуть лишний стакан за очередного минус один. Я так скажу: ахренели совсем. Зарплаты по триста тыщ просят, но не могут пару таблиц запомнить, или хотя бы ознакомиться за день полноценного чтения мануала и увидеть, где ожидание-реальность не совпадают. Зато любят спрашивать, как бы ты реализовал вундервафлю, которую все равно никто никогда не рискнет юзать в продакшене.

Хех, в Dart та же фигня

int x() {
  final isFalse = false;
  final i1 = 1;
  final str = 'x';
  if (str == 'e' && !isFalse ? true : i1 == 1) {
    return 1;
  }
  return 0;
}

А вот python молодец, будьте как питон.

def x() -> int:
    is_false = False
    i1 = 1
    str_ = 'x'
    if str_.__eq__('e') and True if not is_false else i1.__eq__(1):
        return 1
    return 0

так это не тернарный оператор перепиши тоже самое на ифах в джаве или си и будет тебе как в питоне.

А вот python молодец

Сколько нужно выпить чтобы такое распарсить?

Ага, совсем одно и то же.

Должен, одно дело ловить use-after-free, а другое дело вот такое… Тут уже проблема в разработчике.

Это плохой аргумент. Нормально - это вкусовщина.

Вот из недавнего.

сорян за офтоп

Накиньте в Взлетели:

https://varlamov.ru/3912524.html

Особенно про разницу в зарплате.

Те же зарплаты SpaceX - это примерно от 800 тыс до 1 млн рублей в месяц. Зарплата директора NASA $232K - примерно в полтора раза выше зарплаты инженера. Зарплата Рогозина - $450K - примерно в 2 раза выше чем директора NASA и примерно в 120 раз выше зарплаты Российского инженера.

НОРМАЛЬНО ПРИМЕНЯЕМЫЙ тернарный оператор — ни разу.

Тем не менее его слишком легко накрутить в нечитаемую кашу (особенно вложенный), а значит — это будет делаться, время на отладку и ревью будет непроизводительно тратиться и так далее. Поэтому в лучших современных языках — Go и Rust — тернарник отсутствует.

Не зарекайся, еще могут добавить запросто.

Тернарник для тех кто хочет причинять читающим его код людям боль, но Perl не осилил.

Не зарекайся, еще могут добавить запросто.

В Rust вряд ли: там вопросительному знаку нашлось гораздо более полезное применение.

А в Go вопрос долго обсуждается в issues. Тернарника не будет 100%. Наиболее близкое, что будет — встроенная шаблонная функция cond(условие, первый-результат, второй-результат) с ленивым вычислением результатов для обеспечения «short-circuit evaluation». И то очень не хотят вводить такую функцию, потому она будет исключением из правил, а исключения в Go не любят (pun intended, как говорится). Ну, а без ленивости будет обычная скучная библиотечная функция cond с оверхедом в виде обязательного вычисления обоих возможных результатов.

Поэтому в лучших современных языках — Go и Rust — тернарник отсутствует

В Rust с самого начала, if называется

В Rust с самого начала, if называется

Ну да, он там никогда и не нужен был.

Да, пропустил, потому что код валидный. При этом условие «тернарного оператора» явно выделено, и не нужно искать в портянке приоритет тернарного оператора для корректного прочтения этого кода. Собственно, о чем я и говорил ранее.

В Rust нет тернарного оператора. Есть выражение if-else, возвращающее значения (напомню, что unit тоже значение), которое может выполнять как роль традиционного if-else, так и тернарного оператора. При этом оператором оно не является.

В чем принципиальное отличие? Разве выражение с использованием тернарного оператора, не является выражением, возвращающим значение?

В самом начале топика я объяснил разницу. Перечитай, пожалуйста. Дополню вкратце. Выражением является, принципиальное отличие в явном выделении условия.

C-like:

• if-else – блок, ничего не возвращает, изменяет control flow, условие явно выделено.

• :? – выражение, возвращает значение, изменяет control flow, условие не выделено и определяется приоритетом.

ML-like:

• if-else – выражение, возвращает значение (отсутствие значения – тоже значение с т.з. системы типов), изменяет control flow, условие явно выделено.

Не согласен. На примере того же раста, что был выше. Где там явность? Может мне вот не явно Скобочек нет. Явность упирается в то, что я должен быть знаком с синтаксисом и как парсится выражение? Ну, привет, с тернарным оператором явность ровно на том же уровне.

Под явностью я подразумеваю в первую очередь явное отделение условия от веток и окружающего кода. Выражение if-else парсится однозначно, не требуя никаких приоритетов:

if <expr> { } else { }

Отмечу, что скобки вокруг условия в C-like нужны ровно потому, что C-like разрешают

if (cond) a(); else b();

Что примечательно, в том примере обсуждаемая ошибка уже исключена. Я искренне не понимаю, что автор сообщения пытался этим примером показать.

Все равно не согласен. В выражении с тернарным оператором все не менее явно друг от друга отделено.

<expr> ? <expr> : <expr>

Я не понимаю, это троллинг такой? Все, что можно, уже разобрали и объяснили, но ты начинаешь сначала.

Что не так с Java?

Ну ты чо? Мы же уже всё разобрали.

Ты работу наконец сменил?

Нет, как видишь. Ковыряю тоже самое, что досталось в наследство.

Т.е. у вас теперь есть сорцы? Ну так поправьте на человеческий.

Если их тронуть, то может что-то внезапно отвалится в другом месте. Проще переписать заново.

Шо рили деньги во флоатах, брат жив?

Анон, это pivotcube для дельфи. Они у там всех так, не только у нас. А еще оно ранодомно падает и это норма.

может тебе надо ещё и IDE

Мне не надо. Я сразу перепастил этот кусок в другое место и удивлялся, что у меня он работает. Разбираться полез на следующий день.

Короче, ты согласен с тем что условный оператор усложняет понимание кода? Да/нет

Тоже вариант

Нет. Не согласен.

Я как раз весь тред о том, что никакой принципиальной разницы между выражением с тернарником, и выражением с if нет.

Усложняет понимание кода то, как, что и где применяют. И тернарный оператор тут вообще не при чем. Можно нагородить вереницу из любых операторов и конструкций так, что глаза потекут. Или пременить их не к месту, как в ОП посте. Из того, что инструмент применяют не по назначению или нерационально, от этого инструмент плохим не становится. Шурупы в целом тоже можно использовать вместо гвоздей, если захотеть. Но от того, что шурупы можно при должном усердии забить, не делает их плохими.

Спорить я начал с самого начала с утверждением

тернарный оператор – одна из худших фич С-подобных языков

С учетом всех последующих аргументов, под худшую фичу языка, можно подвести абсолютно любую фичу, абсолютно любого языка. На деле же окажется, что худшей фичей может быть лишь сам программист.

Ну учитывая что оба языка отошли от С-like синтаксиса достаточно, просто возьмут не ? и :

будет исключением из правил

Из правил под страхом смерти не усложнять язык и не делать явное неявным? :)

А зачем на ровном месте добавлять лишние возможности выстрелить в ногу? Кое-где исключения уже скорее являются правилом, и использование языка это точно не облегчает.

Долго этот код танцевал? Переписывай.

Долго этот код танцевал?

Года два.

Я не понимаю, это троллинг такой? Все, что можно, уже разобрали и объяснили, но ты начинаешь сначала

На твои аргументы ответили, почему они не аргументы, а ты считаешь что что-то объяснил. Это троллинг такой?

Единственное что отчасти катит – это обязательные скобки в if в C. Но это именно C, а мы тут вроде про идею в целом. Решается кодстайлом, так же как зачастую форсятся фигурные скобки в if.

И, кстати, обязательность круглых скобок в сишном if – синтаксическая глупость, и в не C-like языках она обычно исправлена.

Это не глупость. Тут либо скобочки, либо then.

Либо фигурные скобочки, и в этом больше смысла.

Да и без всяких скобочек зачастую всё однозначно.

А фигурные скобки это не скобочки? Я и написал, либо скобочки, либо then. Без явно отделения условия далеко не все так однозначно, как кажется.

А вот форсить фигурные уже точно глупость.

Я именно про круглые написал в сообщении, на которое ты ответил.

А вот форсить фигурные уже точно глупость

БОльшая, чем форсить круглые?

Ну учитывая что оба языка отошли от С-like синтаксиса достаточно, просто возьмут не ? и :

Go возьмёт в виде функции, Rust не возьмёт (время от времени находятся предлагающие, сразу получают отлуп в виде x = if cond {a} else {b} и чего тебе ещё надо).

Вообще тернарник яркий пример байкшеддинга — незначительные фичи часто обсуждаются намного дольше, чем реально важные.

Из правил под страхом смерти не усложнять язык и не делать явное неявным? :)

Именно. Идейно.

А я писал про любые. Либо условие выделяется круглыми, либо действие фигурными. В первом случае форсятся круглые, во втором фигурные, которые вообще-то для другого предназначены, и выглядят там для обособления действия из одного оператора гораздо глупее, чем круглые для обособления условия из одной переменной.

фигурные, которые вообще-то для другого предназначены

И про круглые то же самое можно сказать. И, если убрать их из синтаксиса if, их точно так же всё равно можно написать, чтобы убрать неоднозначность.

гораздо глупее

Не вижу, чем глупее. Зато вижу, что в типичном if теперь приходится писать и те, и те, а достаточно было одних – фигурных.

Всегда интриговали любители заковыристых вложенных сравнений Зачем ломать голову над тем, что вернет заковыристое, если оно раскладывается в примитивное вложенное? Хороший код = простой код = понятный код Если код не очевиден но его результат то-же не очевиден = плохой, не очевидный результат, особенно когда речь пойдёт о правках через год, когда смысл заковыристости будет давно забыт Ява, при всей своей вербузности, прекрасна именно возможностью писать крайне очевидный и предсказуемый код, где максимальная сложность это вычитать 100500 строчек очевидного кода

Тернарный оператор распарсит всю левую часть как одно выражение

Не жавой единой. Всегда надо скобочки ставить, группировать выражения, а не полагаться на то, как оно под капотом отработает.

Оригинальный код был сразу так написан, или ″&&″ кто-то позже дописал (пытался уточнить условие)?

Ты шо, тру программисты же заклюют.

По факту да, лучше перебздеть чем недобздеть, тем более что большинство реально пишущих код людей сейчас пишут как минимум на нескольких языках активно, и никому не упиралось запоминать тонкости работы определенных языковых возможностей.

тру программисты

это Iron Bug? В нормальных конторах скобки везде в code style прописаны.