Комментарии 22
Кому интересно, мнения в соответствующем RFC разделились примерно поровну:
https://github.com/rust-lang/rfcs/pull/2457
Обычно у людей, которым необходимы нестандартные символы, настроены всякие автозамены аккордов. Набираешь \ a => α, | N | => ℕ, и т. д.
Что вы тогда делаете в коде, где нужны специальные символы, если о них не знаете?
Одно дело использовать символы за пределами ASCII, потому что так удобнее для предметной области — и другое дело, когда это стилистический выбор. В первом случае вы как-нибудь решите для себя вопрос их набора, потому что польза перевешивает неудобства. Второй случай — это только вопрос конвенции.
Можно же научить линтер давать по шапке за идентификаторы lIllI1lи I11lIl1. Точно так же можно гонять и за несогласованные non-ASCII идентификаторы. Но это решает каждый отдельный проект для себя самостоятельно, а не разработчики компилятора за всех.
Другое дело, что эта фича (насколько я сейчас вижу) нужна очень ограниченному кругу разработчиков, а подавляющему большинству это только вредит, то есть во всех проектах где я захочу работать, эту фичу нужно будет явно выключать. Вот нужно мне будет посмотреть код китайских товарищей, а там иероглифы. И… все.
Мне это кажется странным. Логичнее было бы сделать off by default.
обфускация хорошая получается))
а вообще да, должны быть нормальные стандарты.
Просто отрефакторить переименовав и всё. Пусть не вы**ываются.
Как по мне, это одно из самых сомнительных нововведений. Я сомневаюсь, что эта фича найдёт массовое применение. По крайней мере, надеюсь на это.
Пробовали писать транслитом. Получалось хреново. Во-первых, как оказалось, бывает транслитная дислексия. Молодой джун, в остальном весьма справный, не способен прочитать длинный транслит пока медленно, по буквам, не перепишет его нашими буквами. Пара сотрудников постарше регулярно забывали правила транслита, сочиняли нечитаему хрень. Написал им программу, делающую транслит туда-сюда. Но теперь, чтобы прочитать название переменной, трём людям нужно его скопировать и вставить. Во вторых, от транслит у автокомплита в IDE крыша ехала, но как и почему не помню.
В итоге, сначала со злости, а потом на полном серьёзе стали использовать такую систему: любая мало-мальски сложная в переводе переменная называется stvar9475894253, где stvar означает strange variable, а 9475894253 — случайное число, для уникальности имени. И в комментарии написано на русском, что это значит квалитет посадочного места подшипника коленвала. Для долгоживущих переменных с проектом идёт файлик, где эти переменные перечислены, и на русском написано, что они значат. Люди на полном серьёзе всем коллективным бессознательным определили, что так проще, чем возиться с транслитом или переводами.
Уже после, впервые столкнувшись с языками, где есть юникодные имена, я сто раз подумал, как было бы охрененно круто иметь их в том старом проекте. Но при этом они мне больше никогда не понадобились: больше нигде предметная область не просачивалась так активно в код.
С таким подходом к ошибке нужно тщательно поддерживать публичный список кодов ошибок. Следить, чтобы в нём было всё, что нужно. И не было того, что не нужно. Microsoft вот не справилась. Пользователи регулярно жалуются об ошибках с туманными кодами, которые не гуглятся, беспомощной техподдержке и тому, что в итоге нужно было переустановить VCRedist2015. А ещё есть Adobe, у которого публичного списка вообще нет. И техподдержка морозится и отказывается внятно помочь в хоть сколько-то сложном случае. В результате часто вижу заявления типа «Единственный способ починить Adobe — форматнуть весь комп.»
Rust — это язык программирования, позволяющий каждому создавать надёжное и эффективное программное обеспечение.
Если каждый ринется создавать эффективное программное обеспечение... Не эффективное менеджеров уже хватает, а тут еще и эффективные программисты будут - жуть. Большая часть этих каждых просто посмотрит на этот язык и скажет - хрень какая-то, и забудет.
Теперь еще и с юникондными идентификаторами и всем геморроем который это привносит - эмодзи, нормализация строк (привет скорости компиляции), разное направление письма, неоднозначность представления, не отображаемые символы, модификаторы, одинаковые символы могут быть совершенно разными, невозможность набрать на клавиатуре с распечатки. Можно было оставить только латинские буквы, а в IDE заменять пред определенные последовательности на необходимое визуальное представление, но нет нормальные герои любят трудности. Что же продолжим наблюдение.
Первый наброс совсем скучный. А про второй:
> эмодзи, разное направление письма, неоднозначность представления, не отображаемые символы, модификаторы
Разрешили же только подмножество юникода, в котором всего этого нет.
> одинаковые символы могут быть совершенно разными,
Вон даже в коротком анонсе выше показано, что в таких случаях компилятор предупреждение выдает согласно юникодным таблицам схожести (warning: identifier pair considered confusable between `ｓ` and `s`).
> нормализация строк (привет скорости компиляции)
Откуда такие опасения? О.о Разве есть где-то бенчмарки для раста (или прецеденты из других подобных языков), что это заметно сказывается на общей скорости сборки?
> невозможность набрать на клавиатуре с распечатки
Насколько я понимаю суть базовой задумки: если на твоей клавиатуре нет используемых в проекте символов (и ты не знаешь этого языка), то твое участие в нем не предполагается. В случае использования для более близкого перевода формул в код - см выше коммент про аккорды.
> Можно было оставить только латинские буквы, а в IDE заменять пред определенные последовательности на необходимое визуальное представление, но нет нормальные герои любят трудности.
Тоже такое себе - изобретать ide-специфичные велосипеды вместо использования уже готового общепринятого стандарта.
Разрешили же только подмножество юникода, в котором всего этого нет.
Что есть возможность контролировать какие символы допустимы?
Откуда такие опасения? О.о Разве есть где-то бенчмарки для раста (или прецеденты из других подобных языков), что это заметно сказывается на общей скорости сборки?
www.unicode.org/reports/tr15/tr15-29.html
А вы думаете все эти преобразования будут даром.
И такие чудеса вас тоже не смущают?
value=3.14
قيمة =3.14
Что есть возможность контролировать какие символы допустимы?
Я глубоко в вопрос не лез, но да? Текущая реализация опирается же на https://www.unicode.org/reports/tr39 / https://lib.rs/unicode-security
А вы думаете все эти преобразования будут даром
Не даром, конечно, но относительно остальных вычислений при компиляции я бы ожидал пренебрежительно малое время.
И такие чудеса вас тоже не смущают?
Уф, значит RTL таки решили втащить как есть.
"right-to-left scripts can lead to weird rendering in mixed contexts (depending on the software used), especially when mixed with operators. This is not something that should block stabilization, however we feel it is important to explicitly call out. Future RFCs (preferably put forth by RTL-using communities) may attempt to improve this situation (e.g. by allowing bidi control characters in specific contexts)"
Так себе оно отображается в редакторах без специальной поддержки RTL идентификаторов. В текущем виде не особо приятно, мда :(
Не даром, конечно, но относительно остальных вычислений при компиляции я бы ожидал пренебрежительно малое время.
Помимо преобразований, придётся вводить ещё кучу костылей для определения возможных опечаток. Да и одно и тоже слово в юникоде имеет не однозначное представление. Помимо самих имён придётся вводит например похожие имена по начертанию и по звучанию, и строить по ним индексы, что бы находить что же программист имел ввиду до опечатки. Например в C++ с его манглированием имён получаем библиотеки в которыех 90% объёма составляет не код, а идентификаторы (например в boost-е). Помимо самой программы фрагменты кода будут усложнять среды разработки, при отправке его по почте, в форумы, системы контроля версий и месенджеры они могут выглядеть совершенно по разному, не говоря уже о редактировании таких символов. Даже банальное выделение текста может озадачить.
Я к тому что ограниченный алфавит с однозначными правилами это на порядки проще, чем необъятный юникод с не очевидными обычным людям граблями, которые приведут к неожиданным проблемам, которые придётся героически преодолевать, выделяя на это не малые ресурсы. Не только тех кто пишет компилятор и IDE, но и тех кто будет преподавать это студентам, не говоря уже о тех кто будет пытаться описать это в книгах.
Моё мнение это создание ненужных проблем на ровном месте. Лучше оставили только латинские символы, а различные представления решали бы с помощью IDE. Можно даже диаграммы строить и анимацию добавлять. Но при наборе и редактировании текста можно пользоваться обычной клавиатурой.
Вы же знаете, что можно не разделять логику, представление и модель данных, но в результате со временем получим кашу. Тут тоже самое будет. Да и избавится от такого сложнее чем его добавить.
Rust 1.53.0: IntoIterator для массивов, "|" в шаблонах, Unicode-идентификаторы, поддержка имени HEAD-ветки в Cargo