Почему большинство языков программирование разрешают присваивание в условии?

Так собственно то и смущает, что присваивание - выражение (expression), а не инструкция (statement).

Даниил Колесниченко: так все правильно. Ведь результат присваивания - значение, а, стало быть, это выражение. Истина не должна смущать.

Ты какой-то деревянный. То что присваивание возвращает значение, и смущает. Открою секрет, так далеко не во всех языках. На вскидку, это не так в Python, Ruby, Lua, Rust, Haskell.

Даниил Колесниченко: то есть, присваивание не должно вообще возвращать значение, и присваивая a = b, а не должна получать результат присваивания? Судя по всему, деревянный здесь именно ты)

Алексей Николаев: ты сам-то понимаешь что за бред написал? a как раз-таки получает значение, а вот если сделать x = (a = b), то должна быть ошибка компиляции, так как присваивание должно быть не выражением, а инструкцией (оператором). И да, почитай значения слов "выражение", "возвращает", прежде чем спорить с кем-то.

Даниил Колесниченко: ну смотри. x = (a = b) - это норма для многих языков. Зависит от ассоциативности оператора присваивания. Поскольку в php, js и многих других обработка присваивания начинается справа налево, то сперва a будет присвоено значение b. Скобки здесь лишние, т.к. все равно x будет по факту присвоено значение b.

Оператором является собственно оператор, а вот сама комбинация оператора с операндами - выражением. И это нормально. Рекомендую подучить логику.

Алексей Николаев: то, о чём ты говоришь, это не оператор, а операция (путаница происходит из-за того, что в английском языке оно как раз обозначается словом operator). Оператор здесь используется как синоним инструкции (я думал это очевидно, учитывая то, что слово "оператор" написано в скобках рядом со словом "инструкция"). И все эти операнды к тому о чём я говорю никакого отношения не имеют.

Ты в упор не видишь о чём я говорю. Присваивание должно быть отдельной инструкцией, а не выражением и не частью другого выражения. то есть a = b;, и никаких a = (b = (c = d))), if (a = b) {} else {}, foo(a = b) и так далее. Это я описываю случай (читай. внимательно. что. я. пишу.) когда присваивание является инструкцией, но не является выражением. Инструкции могут лишь просто являться частью блока кода, тогда как выражения могут иметь значение, которое может быть передано в другую функцию, присвоено, использовано в условии оператора if и так далее.

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

Даниил Колесниченко: окей, допустим, имеем дело с присваиванием как инструкцией (и я понял все, что ты написал). Но что помешает мне, с точки зрения здравого смысла, взять операцию присваивания в скобки (a = b), и поместить ее в другую инструкцию, например, вернуть через return? Какая турбулентность логики может это запретить? Каковы реальные причины такого запрета, который бытует в серьезных языках типа паскаля или там плюсов? Не идут ли корни данного поведения к древним временам, когда иначе сделать было просто невозможно технически?

После присваивания всегда есть результат - переменная, которой было присвоено значение. Можно рассматривать присваивание в if как своего рода shorthand для работы с измененной переменной - суть от этого не изменится, потому что, повторюсь, присваивание всегда изменяет данные, т.е. есть результат, с которым можно работать, а другие инструкции - if, return, goto, результат не генерируют, и данных не изменяют. В PHP \ JS, на мой взгляд, как раз этот момент один из наиболее логичных, разделение выражений и инструкций по принципу "изменяют \ не изменяют" ("имеют значение \ не имеют значения").

С твоей точки зрения получается, что я не смогу использовать инкремент в том же for, потому что инкремент внутри себя содержит присваивание переменной большего значения, i++ тождественно i += 1 или i = i + 1. Что мне, технически, помешает заменить один вариант другим, если они по действию идентичны? Более того, i += 1 можно представить как i = (a += 1) - в скобках a будет инкрементирована, и мы придем к фактическому выполнению i = a. Это все абсолютно нормально работает, и на мой взгляд, работать должно. Помешать этому могут только искусственные ограничения. А рекомендации подучить терминологию от человека, который настолько глуп, что не может взглянуть на ситуацию под другим углом, звучат смешно.

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

Кстати, забавно, по-твоему получается, что присваивание должно возвращать результат. На самом деле, в записи x = if true { 1 } else { 0 } как минимум не меньше логики, чем в x = a = b. Ну то есть по факту получается такой тернарный оператор, только выглядит по-человечески и позволяет выполнять не одно выражение, а целый блок, и возвращать последнее. Это работает так в Rust, Haskell, OCaml, CoffeeScript, есть даже драфт для похожего нововведения в ECMAScript (потому что фича реально нужна, особенно полезна она могла бы быть в React-компонентах).

На счёт цикла for - так ли он нужен (в его сишном варианте)? Чтобы перебрать числа в промежутке, во многих языках (D, Rust, Swift, Clojure, Python, CoffeeScript, Haskell) есть ranges (как правило, ленивые): for i in range(10) или for i in 0..10. Чтобы перебрать элементы коллекции, есть итераторы (C++, D, Rust, Swift, Clojure, Python, JavaScript и куча других языков): for x in [1, 2, 3]. Ну я молчу про методы вроде map и forEach, которые опять-таки в большинстве языков реализованы для типов коллекций и которые зачастую позволяют писать более читабельный (а в случае с JS-движком v8 - и более производительный) код. Остальные же случаи использования for нормально реализуются с помощью while.

А почему я считаю, что assignment is an expression - плохой подход, так это потому, что он позволяет в безобидной конструкции, вроде проверки условия, менять переменные, причём довольно легко случайно сделать это вместо сравнения (написать = вместо == - и не такие опечатки бывают), и код может компилироваться и ошибка может довольно долго не проявляться. Короче, лишний источник багов. Проще написать лишнюю строку, если это поможет писать код с меньшим количеством ошибок.

На счёт "помешать могут только искусственные ограничения" - почти вся безопасность разработки ПО строится на искусственных ограничениях. Статическая система типов - искусственное ограничение, позволяющее не пускать в продакшн код, неправильно использующий типы. Сильная типизация - искусственное ограничение, предотвращающее неожиданное для разработчика поведение, запрещая неявные преобразования типов (или сводя их к минимуму). Лайфтаймы и заимствования - искусственное ограничение, позволяющее безопасно работать с памятью, не тратя ресурсы на сборщик мусора. И так далее.