Comments 21
а также операторов на всякие случаи жизни, например, <=>, как в Perl'е,
позволит писать более лаконичный код.
Возможно стоит добавить вариант — «соль не нравится/ее уже слишком много/не нужна».
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++
.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.
------.--------.>+.>.
не люблю соль
Боюсь что это одна из фишек Ржавчины, язык с самого начала задумывался как знатно просоленный. Начиная с простейших вещей, вроде того что для создания изменяемой переменной надо писать не просто let a = 0;
, а let mut a = 0;
.
более лаконичный код
Опять же, насколько я себе представляю, приоритетом является "написание удобного в поддержке кода", а не короткого. Есть мнение что эти цели часто друг другу противоречат.
пусть лучше будет больше сахара
За аккуратное и вдумчивое насыпание сахара отвечает https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html, по итогам порядочно RFC уже появилось и еще будет.
А "соль" понятие размытое же. Возможен же язык, где не надо явно помечать изменяемую переменную? Вполне возможен, их полно. Раз от mut
ов можно было бы избавиться при желании, значит это в каком-то смысле вполне себе "соль".
Были же предложения ввести в язык var
как сокращение для let mut
— их отвергли именно как противоречащие "соленому" духу языка, не поощряещему мутабельность.
В общем, я за оценку с точки зрения оценки именно результатов того или иного принятого решения
в итоге печатать корректный с точки зрения мутабельности код проще, чем некорректный.
Ну, эм, да. Соль и нужна для того что бы подталкивать людей писать хороший код. :)
а ничего что winnapi появилось до того как приняли ansi C и никаких const в языке ещё не было.
Что вы понимаете под "константность в объявлениях не работает"?
В объявлении C-функции cv-квалификаторы аргументов осмыслены.
Но не возвращаемого значения.
int func_dumb(char *str);
int func_smart(const char *str);
func_smart("somestring"); // Oк
func_dumb("somestring"); // Ошибка компиляции - invalid cast
Но проблема на самом деле даже не в том, что не хватает каста, а в том, что из сигнатуры функции непонятно, меняет ли она строку. А чтобы стало понятно, надо лезть в MDSN где как правило никаких подробностей ни на русском ни на английском.
// test08.c
int func_dumb(char *str);
int func_smart(char const *str);
void test() {
func_dumb("abc");
func_smart("abc");
}
Результат компиляции C:
XXXX$ clang -Wall -Wextra -c -std=c99 test08.c
Ничего, none, nada.
Результат компиляции C++: ворнинг.
XXXX$ clang++ -Wall -Wextra -c -std=c++11 test08.c
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated]
test08.c:6:13: warning: ISO C++11 does not allow conversion from string literal to 'char *' [-Wwritable-strings]
func_dumb("abc");
^
1 warning generated.
Пример плохой неявности — приведение типов при сравнении (==) в javascript.
Пример хорошей неявности — подстановка в метод класса self первым аргументом в python. (В нём есть пример хорошей явности — self явно объявляют в списке аргументов).
Хз, Я за последние пару лет видел порядочно обсуждений ЯП "на RFCs или на internals-форуме" (и еще много где), которые могли бы пройти намного более гладко, если бы участники сразу более точно указывали какой вышеуказнный сорт "явности" они имеют ввиду.
Неявность