Ну и как бы вкусно писать full-stack на одном языке, под все платформы, вместе с бекендом. Кажется, прецедентов ещё не было.А как же Clojure/ClojureScript? В отличие от Kotlin оно как раз вполне юзабельно на фронтенде и обросло даже своей экосистемой (в основном завязанной на React).
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.= вместо == - и не такие опечатки бывают), и код может компилироваться и ошибка может довольно долго не проявляться. Короче, лишний источник багов. Проще написать лишнюю строку, если это поможет писать код с меньшим количеством ошибок.
a = b;, и никаких a = (b = (c = d))), if (a = b) {} else {}, foo(a = b) и так далее. Это я описываю случай (читай. внимательно. что. я. пишу.) когда присваивание является инструкцией, но не является выражением. Инструкции могут лишь просто являться частью блока кода, тогда как выражения могут иметь значение, которое может быть передано в другую функцию, присвоено, использовано в условии оператора if и так далее.
a как раз-таки получает значение, а вот если сделать x = (a = b), то должна быть ошибка компиляции, так как присваивание должно быть не выражением, а инструкцией (оператором). И да, почитай значения слов "выражение", "возвращает", прежде чем спорить с кем-то.
Ок, расширение файла "с", но ваш "проект" скомпилирован как С++
Ну и документацию на "С" чтоли почитайте.Ты в курсе, что то, что ты скинул, это ну как бэ ни разу не документация.
Я бы на вашем месте с вашей страницы на github.io убрал "С" чтобы не позориться.Я же не написал "C89". Не вижу смысла ограничивать себя возможностями старых стандартов, лол. То что ты не знаешь возможностей новых стандартов - исключительно твои проблемы.
Embarcadero C++ BuilderОру с тебя, зачем ты этим пользуешься?
Нуу возможно имелась ввиду компиляция в какой-нибудь WebAssembly, хотя мне пока не совсем ясно куда вообще WASM приведёт фронтенд и начнут ли браузерные клиенты массово писать на языках, компилируемых в WASM. С другой стороны, трансляция в JS - это в принципе нормально, но с Kotlin я вижу проблему вот в чём: Kotlin статически типизирован, при этом система типов у него отличается от системы типов какого-нибудь TypeScript. Это значит что для использования любого браузерного API и любой JS-библиотеки придётся писать типизированные обёртки. И из-за несовместимости с TypeScript просто взять TS-декларации (*.d.ts) нельзя. Можно конечно писать обёртки не заморачиваясь с типами (везде
Any), но во-первых, объявлять-то функции и классы все равно придётся явно, во-вторых, тогда теряем преимущества статической типизации Kotlin. Почему на мой взгляд ClojureScript так прижился во фронтенде, так это благодаря крайне лёгкой интеграции с платформой (в том числе благодаря динамической, как и у JS, типизации).