Open source
Rust
Компиляторы
Программирование
Системное программирование
Комментарии 21
0
По поводу опроса: не люблю соль, пусть лучше будет больше сахара,
а также операторов на всякие случаи жизни, например, <=>, как в Perl'е,
позволит писать более лаконичный код.

Возможно стоит добавить вариант — «соль не нравится/ее уже слишком много/не нужна».
0
Что то вроде такого?)

++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++
.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.
------.--------.>+.>.
+4
не люблю соль

Боюсь что это одна из фишек Ржавчины, язык с самого начала задумывался как знатно просоленный. Начиная с простейших вещей, вроде того что для создания изменяемой переменной надо писать не просто let a = 0;, а let mut a = 0;.


более лаконичный код

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


пусть лучше будет больше сахара

За аккуратное и вдумчивое насыпание сахара отвечает https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html, по итогам порядочно RFC уже появилось и еще будет.

+1
Начиная с простейших вещей, вроде того что для создания изменяемой переменной надо писать не просто let a = 0;, а let mut a = 0;.

Это не соль, это better defaults.

+2

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


Были же предложения ввести в язык var как сокращение для let mut — их отвергли именно как противоречащие "соленому" духу языка, не поощряещему мутабельность.

+1
в итоге печатать корректный с точки зрения мутабельности код проще, чем некорректный. Вон в си для иммутабельности нужен const, и в итоге win api много где const-некорректен. А ведь это должен быть пример хорошего кода.

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

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

0

а ничего что winnapi появилось до того как приняли ansi C и никаких const в языке ещё не было.

+2
а что, за почти 30 лет с момента появления ansi C нельзя было дописать const в несколько мест? С учетом того, что это никак не затронет ни легаси код, ни бинарную совместимость?
0
А ничего, что в C константность в объявлениях не работает? А что написано в определениях в WinAPI не видно?
0

Что вы понимаете под "константность в объявлениях не работает"?

0
В C cv-квалификаторы возвращаемых значений и параметров в объявлениях не имеют смысла, обычно вызывают предупреждения и, соответственно, редко используются.
В объявлении C-функции cv-квалификаторы аргументов осмыслены.
Но не возвращаемого значения.
0
поясню зачем нужна const-корректность на простом примере:
int func_dumb(char *str);
int func_smart(const char *str);

func_smart("somestring"); // Oк
func_dumb("somestring"); // Ошибка компиляции - invalid cast

Но проблема на самом деле даже не в том, что не хватает каста, а в том, что из сигнатуры функции непонятно, меняет ли она строку. А чтобы стало понятно, надо лезть в MDSN где как правило никаких подробностей ни на русском ни на английском.
0
// 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.

+2
Когда говорят про неявность, подразумевают ровно одно: сайд-эффект грамматики не очевиден читающему, его трудно сформулировать кратким правилом, или он сильно зависит от рантайм-значений.

Пример плохой неявности — приведение типов при сравнении (==) в javascript.
Пример хорошей неявности — подстановка в метод класса self первым аргументом в python. (В нём есть пример хорошей явности — self явно объявляют в списке аргументов).
+2

Хз, Я за последние пару лет видел порядочно обсуждений ЯП "на RFCs или на internals-форуме" (и еще много где), которые могли бы пройти намного более гладко, если бы участники сразу более точно указывали какой вышеуказнный сорт "явности" они имеют ввиду.

0
Добавлю, что self первым аргументом в сигнатуре не просто так — он выражает тип передачи — заимствование, изменяемое заимствование или перемещение.
0
fcoder Имел ввиду передачу первым аргументом self в расте. И, да в расте это необходимо, чтобы определять тип передачи, а не просто для явности как в питоне.
0
Все-таки мне кажется, что «многословность» или, например, «зашумленность», «захламленность», было бы лучше, чем «шумность». Без оригинального verbosity я бы затруднялся понять, что именно имеется в виду.
+1

Ага, мы над этим задумывались, потому оригинал на всякий и указан. Местами там используется noise — в итоге ни один из вариантов перевода на 100% нормальным не выглядит.


захламленность

Это точно плохой вариант из-за слишком негативной окраски :)

Только полноправные пользователи могут оставлять комментарии. , пожалуйста.