Rust: Проблема с отслеживанием идентификаторов, отличных от ASCII (функция «non_ascii_idents»)

/cc @rust-язык/язык

выдвижение

копия @SimonSapin

Видимо реализуем так: http://www.unicode.org/reports/tr31/ или что-то в этом роде.

Я хотел бы, чтобы это стабилизировалось, но потребуется некоторая работа, чтобы убедить себя в том, что мы поступаем правильно.

Я понятия не имею, что здесь правильно. В дополнение к рекомендациям по Unicode мы могли бы захотеть посмотреть, что на самом деле делают другие языки, и какие отчеты об ошибках или критику они получают. Или это уже было сделано, когда эта функция впервые была представлена?

@SimonSapin
C и C++ используют http://unicode.org/reports/tr31/#Alternative_Identifier_Syntax (с некоторыми незначительными ограничениями), и я не видел никаких жалоб на это на форумах isocpp или списках проблем :)
Обзор проблемы: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1518.htm
Реализация в Clang: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/UnicodeCharSets.h?view=markup
копия https://github.com/rust-lang/rust/issues/4928

Также есть проблема с нормализацией идентификаторов и сопоставлением имен юникода mod с именами файловой системы (в OS X, IIRC), но я не могу найти соответствующую ссылку здесь: https://github.com /rust-lang/rust/issues/2253. (В худшем случае неинлайновые mod s и extern crate s могут быть принудительно переведены в ASCII)

Да, #2253 — это известная мне большая проблема, которая заставляет меня беспокоиться о преждевременной стабилизации идентификаторов, отличных от Unicode.

(Обсуждение здесь более широкое и, возможно, может быть разделено на два потока; например, мы _могли_ выбрать один путь нормализации для идентификаторов, а другой - для содержимого строковых литералов.)

мы можем перенести это обсуждение в репозиторий RFCS, например, на https://github.com/rust-lang/rfcs/issues/802 .

Я согласен с тем, что эта функция заслуживает того, чтобы пройти через процесс RFC.

Я переназначил эту проблему, чтобы отслеживать стабилизацию (или устаревание и т. д.) шлюза функций non_ascii_idents .

После обсуждения на собрании команды lang мы решили, что да, RFC будет правильным решением. Нам нужно что-то, что собирает решения из других языков, анализирует их плюсы и минусы и предлагает подходящий выбор для Rust. Это достаточно спорный и сложный вопрос, поэтому его следует донести до всего сообщества, тем более, что многие из нас, ежедневно взламывающих Rust, в любом случае не имеют большого опыта работы с не-ASCII.

сортировка: P-низкий

Пометка «низкая», поскольку в настоящее время RFC отсутствует, а, следовательно, нет контента, требующего действий.

копия https://github.com/rust-lang/rust/issues/7539

В JavaScript, Perl 5 и Perl 6 эта функция доступна.
JavaScript (Файрфокс 50)

function Слово(стойност) {
  this.стойност = стойност;
}
var здрасти = new Слово("Здравей, свят");
console.log(здрасти.стойност) //Здравей, свят

Перл >=5.12

use utf8;
{
  package Слово;
  sub new {
    my $self = bless {}, shift;
    $self->{стойност} = shift;
    $self
  }
};
my $здрасти = Слово->new("здравей, свят");
say ucfirst($здрасти->{стойност}); #Здравей, свят

Perl6 (это не просто следующая версия Perl. Это новый язык)

class Слово {
  has $.стойност;
}

my $здрасти = Слово.new(стойност => 'здравей, свят');
say $здрасти.tc; #Здравей, свят

Я был бы рад увидеть это и в Rust.

Что бы это ни стоило, идентификаторы в ECMAScript 2015 основаны на синтаксисе идентификатора по умолчанию из Приложения № 31 к стандарту Unicode .

Perl с use utf8; использует регулярное выражение ниже, с XID_Start и XID_Continue предположительно также из UAX # 31.

/ (?[ ( \p{Word} & \p{XID_Start} ) + [_] ])
        (?[ ( \p{Word} & \p{XID_Continue} ) ]) *    /x

Да! Спасибо @SimonSapin!

Для Python это <XID_Start> <XID_Continue>* .

Таким образом, похоже, что многие языки программирования, которые позволяют использовать идентификаторы, отличные от ASCII, основаны на одном и том же стандарте, но в деталях каждый из них делает что-то немного отличающееся…

Я лично хотел бы видеть поддержку идентификаторов, связанных с математикой. Например, ∅ (и операторы множеств, такие как ∩ и ∪). Преобразование уравнений из исследовательских работ/спецификаций в код часто является ужасным процессом, результатом которого является многословный и трудный для чтения код. Возможность использовать в коде те же идентификаторы, что и в математических уравнениях статьи, упростила бы реализацию и облегчила бы проверку и сравнение кода с уравнениями статьи.

В чем конкретно смысл этой функции? Помимо добавления возможности создавать по-настоящему уродливую смесь разных языков в вашем коде (английский — единственный по-настоящему международный язык), это не дает никаких преимуществ в плане функциональности языка. Или это поддержка юникода ради поддержки юникода?

@DoumanAsh Не каждая программа является международной, и свободное владение английским языком не обязательно является требованием для программирования.

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

Вариант использования, который я вижу, не для написания производственного кода, а для обучения. Мне очень неприятно говорить людям, что они должны свободно владеть английским, чтобы стать программистами. Другая ситуация, когда вы пишете пользовательский интерфейс на иностранном языке, если в вашем пользовательском интерфейсе есть текстовое поле с надписью «příjmení», но вы в конечном итоге помещаете значение в переменную с именем «фамилия», что странно. Еще более странно, если у вас есть поле с именем «rodné_číslo» (чешский национальный идентификационный номер). Для этого нет аналогичного английского слова. Так что, если бы я писал чешское налоговое или банковское приложение, мне пришлось бы использовать странное имя без веской причины. В любом случае такое приложение не будет переносимо на другие языки.

Еще одна веская причина для этого заключается в том, что лингвистам часто приходится использовать нотацию IPA в именах переменных. Английские названия символов IPA могут быть смехотворно длинными. Например, звук r в американском английском языке в слове red транскрибируется как один символ ɹ̠, но называется постальвеолярным ретрофлексивным аппроксимантом. https://en.wikipedia.org/wiki/Alveolar_and_postalveolar_compilers Итак, если я пишу программу преобразования текста в речь, я мог бы разумно написать fn say_ɹ̠() вместо fn say_post_alveolar_retroflexive_approximant() .

Что касается не мнения, я думаю, что здесь будет интересная дискуссия относительно того, какие кодовые точки Unicode могут быть частью имени переменной. Например: Могу ли я назвать переменную price€ ? Вероятно, нет, я не думаю, что price$ работает, не так ли? Могу ли я создать макрос →![] для генерации векторов? Я знаю, что кто-то может захотеть это сделать, но → — это «математический символ» http://www.fileformat.info/info/unicode/char/2192/index.htm . Поэтому при лексировании нам нужно принять решение о том, какие кодовые точки приемлемы, а какие нет, и, возможно, rust не должен просто тупо спрашивать стандарт юникода, является ли что-то буквой или нет.

@timthelion в текущей реализации Rust не просто тупо спрашивает стандарт юникода, является ли что-то буквой или нет — он полагается на свойства юникода XID_Start и XID_Continue , которые имеют правильное и интуитивно понятное поведение во всех ваших примерах.

• say_ɹ̠ разрешено, потому что и 'ɹ' , и '̠' являются XID_Continue.
• price€ и price$ не разрешены, поскольку '€' и '$' не являются XID_Continue.
• →![] не допускается, поскольку '→' не является XID_Start.
• příjmení и rodné_číslo разрешены.

@dtolnay спасибо за объяснение. Надеюсь, вы не обиделись на то, что я употребил слово «тупой», возможно, это было неудачное слово.

Нет, просто указываю на то, что великие умы думают одинаково, и у замечательных людей из технического комитета Unicode были те же проблемы, что и у вас.

Я могу придумать другие варианты использования в производстве.

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

На данный момент я думаю, что нет никаких сомнений в том, что у нас много случаев. Осталось выяснить детали:

• Какие именно символы должны быть разрешены. Например, пунктуацию, отличную от ASCII, вероятно, следует исключить.
• Какая нормализация должна быть выполнена: два идентификатора могут быть представлены с разными кодовыми точками (разные байты UTF-8 в исходных файлах), но при этом считаться эквивалентными.

Несколько других языков согласуются с Приложением № 31 к стандарту Unicode, но имеют небольшие различия в деталях. В идеале мы должны выяснить, чем вызваны эти различия, чтобы решить, что лучше для Rust.

https://rosettacode.org/wiki/Unicode_variable_names содержит некоторую информацию для многих языков.

Я согласен с @SimonSapin - никто не сомневается, что это будет полезно. Проблема в том, что не существует стандартного решения, и многие из нас (например, я) не в состоянии оценить компромиссы. Я подозреваю, что нам не хватает кого-то, кто собирал бы ограничения и давал рекомендации. Я подозреваю, что на данный момент любое решение было бы предпочтительнее, чем отсутствие решения, хотя я определенно предпочел бы следовать какому -то прецеденту (в идеале, спецификации или приложению Unicode, но, возможно, и другому языку), чем просто принять еще один набор правил.

@nikomatsakis Было бы неплохо исследовать, что именно мотивировало небольшие различия между различными языками, но если никто не возьмется за это исследование, и мы все равно захотим продолжить, то я думаю, что в точности следуя UAX # 31 (что, я считаю, является нашей целью). текущая реализация делает) является прекрасным значением по умолчанию.

Возможно, стоит пройти процесс RFC с подробным проектом, даже если он соответствует текущей реализации. (Какие символы можно использовать, как они нормализуются/сравниваются на эквивалентность, как мы работаем с будущими версиями Unicode и т. д.) Я предлагаю тому, кто пишет этот RFC, прочитать UAX 31 сверху вниз хотя бы один раз.

Мы также можем рассмотреть возможность создания нового (или, что более вероятно, использования ограниченного подмножества одного из существующих профилей) профиля PRECIS [1] для идентификаторов. Это позволило бы нам нормализовать идентификаторы, которые должны считаться одинаковыми, даже если они немного отличаются (например, для локалей с клавиатурами, которые выводят текст, который выглядит одинаково, но немного отличается в представлении Unicode), а также обеспечивает четкое и краткий набор правил для определения допустимого идентификатора Rust.

Я не знаю о каких-либо существующих реализациях среды PRECIS на Rust (я думаю, что большая часть инфраструктуры Unicode, необходимой для ее создания, все еще отсутствует, но это, вероятно, придется исправить в любом случае).

Я бы не назвал себя экспертом, но я помог создать одну реализацию PRECIS и в целом знаком с RFC и некоторыми подводными камнями и ошибками, поэтому я был бы рад помочь (или обратиться за помощью к рабочей группе PRECIS) где нужно.

[1] [RFC 7564] (https://tools.ietf.org/html/rfc7564): Структура PRECIS: подготовка, применение и сравнение интернационализированных строк в прикладных протоколах

Хорошая мысль о персонажах, которые выглядят одинаково. Вот википедия
статья по вопросу
https://en.wikipedia.org/wiki/Duplicate_characters_in_Unicode

Вот статья, в которой объясняется, что повторяющиеся символы из
азиатские сценарии в основном унифицированы:

https://people.w3.org/rishida/scripts/chinese/

11.04.2017, 21:01, Сэм Уайтд написал:
>

Мы также можем рассмотреть возможность создания нового (или, что более вероятно, использования
ограниченное подмножество одного из существующих профилей) профиль PRECIS [1]
для идентификаторов. Это позволит нам нормализовать идентификаторы, которые
следует считать одинаковыми, даже если они немного отличаются (например,
для локалей с клавиатурами, которые выводят текст, который выглядит одинаково,
но немного отличается в своем представлении Unicode), а также предоставить
четкий и краткий набор правил для определения того, что является действительным Rust
идентификатор.

Я не знаю о каких-либо существующих реализациях PRECIS на Rust.
framework (много инфраструктуры Unicode, необходимой для создания одного
все еще отсутствует, я думаю, но это, вероятно, придется исправить
как-то так или иначе).

[1] RFC 7564 https://tools.ietf.org/html/rfc7564 : Платформа PRECIS:
Подготовка, применение и сравнение интернационализированных строк
в протоколах приложений

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/rust-lang/rust/issues/28979#issuecomment-293367700 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/ABU7-IMgXefW2yZYyM0tn8qLhpGFw0bSks5ru84GgaJpZM4GM3Lj .

@SamWhited Почему PRECIS вместо Unicode NFC или NFKC?

Почему PRECIS, а не NFC или NFKC Unicode?

TL:DR — Нормализация — это всего лишь один шаг, который мы хотели бы сделать при определении того, является ли что-то допустимым идентификатором. Другие операции также могут (или не должны) выполняться.

@SimonSapin Нормализация Unicode — это всего лишь один шаг в профиле PRECIS (так что на самом деле мы будем использовать нормализацию; возможно, NFC, если предположить), однако PRECIS охватывает более широкий спектр вещей. Например, формы нормализации не выполняют сопоставление ширины (я так думаю?), поэтому FullWidth не будет тем же идентификатором, что и ＦｕｌｌＷｉｄｔｈ . Если вы используете клавиатуру, которая хочет набирать текст полной ширины, это может быть проблемой (это, вероятно, больше проблема с восточноазиатскими символами, чем с латинскими символами, но, возможно, кто-то из локали, которая использует текст полной ширины, мог бы звоните и скажите мне, если я каким-либо образом искажаю проблему). Кроме того, профиль PRECIS может включать в себя определение подмножества разрешенных свойств символов (например, букв, цифр, дефисов и начинается с буквы или что-то в этом роде).

_Отказ от ответственности:_ Я на самом деле не думал, будет ли желательно отображать полноширинный текст или нет; это просто пример. Очень может быть, что нормализация — это все, что имеет значение, или, может быть, нам вообще не нужно делать какое-либо отображение; Go только проверяет, имеют ли идентификаторы свойство letter или number, я думаю, поэтому, если они обходятся только этим, может быть, это тоже хорошо для нас. Конечно, нужно больше думать.

Дальнейшее чтение: это то, что делает спецификация Go (что намного проще, чем то, что я предложил, что может быть или не быть хорошо): https://golang.org/ref/spec#Source_code_representation

Что использует PRECIS? Есть ли язык программирования?

Что использует PRECIS? Есть ли язык программирования?

Я не уверен, что делает любой язык, кроме Go .

Связанная проблема с Go 2: golang/go#16033

Во вторник, 11 апреля 2017 г., в 14:07:49 -07:00 Сэм Уайтд написал:

Например, формы нормализации не отображают ширину, поэтому FullWidth не будет тем же идентификатором, что и ＦｕｌｌＷｉｄｔｈ .

NFKC делает это:

Python 3.6.0 (default, Jan 16 2017, 12:12:55)
[GCC 6.3.1 20170109] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> ＦｕｌｌＷｉｄｔｈ = 1
>>> FullWidth
1

--
С наилучшими пожеланиями,
lilydjwg

@SamWhited , в вашей первой ссылке я нахожу:

identifier = letter { letter | unicode_digit } .
letter        = unicode_letter | "_" .

Но, насколько я могу судить, Go в настоящее время не выполняет нормализацию, и использование PRECIS является предложением. Это правильно?

Но, насколько я могу судить, Go в настоящее время не выполняет нормализацию, и использование PRECIS является предложением. Это правильно?

@SimonSapin это правильно; ну, даже не совсем предложение, просто идея, которую нужно обдумать, как этот вопрос (извините, перечитайте это предложение и мою ссылку, и она была плохо сформулирована; я не хотел предположить, что она действительно использует это прямо сейчас, просто я не знаю, что на самом деле делает что-либо, кроме Go, для обработки идентификаторов, отличных от ASCII).

@SimonSapin

Возможно, стоит пройти процесс RFC с подробным проектом, даже если он соответствует текущей реализации.

👍

Я просто читал UAX #31 , чтобы увидеть, что они сделали, и еще одно преимущество использования профиля PRECIS выделилось для меня: точно так же, как отказ от stringprep и использование вместо него PRECIS, он обеспечивает способ быть совместимым и гибким в будущем для версий Unicode ( путем работы с производными свойствами кодовых точек, а не с отдельными кодовыми точками).

Хотя TR31 имеет концепцию « неизменяемых идентификаторов », помогающую решить эту проблему, он фактически представляет собой несколько менее ограничительную версию протокола PRECIS, полученного из класса произвольной формы, но без соображений, которые PRECIS дает в отношении порядка, в котором правила должны быть применяется (я не думаю?), он также не охватывает крайние случаи, охватываемые структурой PRECIS, такие как использование греческой конечной сигмы, или некоторые из крайних случаев вокруг хангыль джамо (опять же, я не эксперт ни в одном из этих , но для этого и существует PRECIS, специалисты уже сделали свою работу).

он обеспечивает совместимость и гибкость в будущем для версий Unicode (путем работы с производными свойствами кодовых точек, а не с отдельными кодовыми точками).

Я не понимаю этот момент. XID_Start и XID_Continue являются производными свойствами.

Я не понимаю этот момент. XID_Start и XID_Continue являются производными свойствами.

Возможно, тогда я неправильно понял UAX 31; мне показалось, что для этого требуется определенная версия Unicode. Перечитывая, я не могу понять, откуда я это взял.

Не уверен, что это подходящее место для публикации, но некоторые интересные проблемы, вероятно, возникнут при анализе математических символов. Этого легко избежать, записав имена переменных, но это может быть важно, если целью является лучшая корреляция с реальными уравнениями.

Например, Δ (верхний регистр) против δ (нижний регистр) на следующем снимке экрана. Линтер не является /неправильным/, но также не имеет смысла применять здесь требование змеиного случая.

можно ли разрешить смайлики в именах переменных, даже если они не XID Start/Continue, как в Swift?

@fwrs , эмодзи сейчас намного сложнее, чем символы, не являющиеся эмодзи.

Благодаря некоторым поставщикам теперь у вас могут быть последовательности соединения эмодзи (ZWJ), которые просто продолжают менять свои цвета и мелкие детали, многие из которых не обязательно видны невооруженным глазом.

Кроме того, определение Emoji быстро расширяется каждый год, что не является чем-то, что требуется языкам программирования системного уровня, которые хотят быть стабильными и надежными.

Так что, хотя это мило, я не думаю, что это хорошо согласуется с целями Rust. Но языки сценариев/образовательные языки на основе ржавчины могут выиграть от разрешения эмодзи, в зависимости от их целей.

@ryankurte В вашем примере есть семантическая проблема: вы расшифровываете математические формулы, но использовали U + 0394 ГРЕЧЕСКАЯ ЗАГЛАВНАЯ БУКВА ДЕЛЬТА, а не U + 2206 ПРИРАБОТКА. Первая является буквой греческого алфавита и поэтому имеет отображение регистра; последний является математическим символом и не является таковым.

Я хотел бы связать этот комментарий: https://github.com/rust-lang/rust/issues/4928#issuecomment -343137316

Я не видел здесь возможности включить атаки на основе гомоглифов (если кто-то упомянул о них, пожалуйста, не обращайте внимания на шум), но я просто заполнил обрывочную проблему , чтобы запросить lint, который предупреждает о коде, подобном этому:

#![feature(non_ascii_idents)]
fn main() {
    let a = 2;
    let а = 3;
    assert_eq!(a, 2);  // OK
    assert_eq!(а, 3);  // OK
}

В двух словах, эти два a являются разными символами юникода, поэтому вторая привязка let не затеняет первую, и обе утверждают, что они проходят (похоже, что игровая площадка не поддерживает идентификаторы юникода, поэтому единственный способ попробуйте это локально; работает для меня).

Эта «функция» может быть использована для введения эксплойтов в программы на Rust, которые труднее обнаружить, в частности, учитывая, что теневые привязки let многими считаются идиоматическими Rust, в том числе и я.

PS: эта «фича» может быть полезна в закулисных соревнованиях по Rust, хотя эта #![feature(non_ascii_idents)] должна вызвать у некоторых удивление :)

@gnzlbg Я полагаю , что уже есть некоторая поддержка обнаружения путаницы, чтобы люди не заменяли ваши точки с запятой на греческие вопросительные знаки и тому подобное, но я не знаю, применимо ли это к идентификаторам. Если это так, то это решает эту проблему; если нет, то, по крайней мере, у нас есть готовые инструменты для этого.

Я немного обеспокоен тем, что это кандидат на закрытие и удаление кода из компилятора, потому что какое-то время он не претерпел значительных изменений и требует RFC. Меня очень волнует, что Rust является языком 21-го века, что означает Unicode, и что Rust дружелюбен к не говорящим по-английски программистам. Чего мне не хватает, так это возможности написать RFC.

@Кетсубан

Я считаю, что уже есть некоторая поддержка обнаружения путаницы, чтобы люди не заменяли ваши точки с запятой на греческие вопросительные знаки и тому подобное, но я не знаю, применимо ли это к идентификаторам.

да, я думаю, что, как предложил @oli-obk в проблеме clippy, реализация Rust вместо этого просто использовала бы последний официальный список путаницы:

http://www.unicode.org/Public/security/revision-06/confusables.txt

Атаки на основе гомоглифов можно предотвратить. Однако этот список необходимо будет синхронизировать, но это то, что можно автоматизировать как часть системы сборки.

@Кетсубан

Если вас это волнует, существуют другие языки, поддерживающие юникод в своих идентификаторах, и эти языки имеют процессы, похожие на процесс RFC. Вы можете начать с проверки тех. Кто знает, может быть, вы можете просто объединить их с отзывами в этом выпуске и запустить предварительный RFC на форуме внутренних органов? С этого момента речь идет просто о включении/обсуждении обратной связи с другими, и прежде чем вы это узнаете, у вас будет готовый RFC.

В каком-то смысле я надеюсь, что мы навсегда останемся с идентификаторами ASCII. Обработка идентификаторов Unicode — это огромная проблема с совместимостью. Некоторые из наиболее причудливых примеров сопоставлений NFKC заключаются в том, что подобные вещи сопоставляются с одним и тем же идентификатором:

>>> ℌ = 1
>>> H
1
>>> Ⅸ = 42
>>> IX
42
>>> ℕ = 23
>>> N
23
>>> import math
>>> ℯ = math.e
>>> e
2.718281828459045
>>> ℨ = 2
>>> Z
2

@mitsuhiko В реальном мире есть такая боль. Мы не можем просто игнорировать эту проблему, потому что с ней трудно справиться, и она включает в себя функцию, которая вам _лично_ не нужна.

Кроме того, текущий RFC явно предлагает NFC вместо NFKC после большого количества обсуждений примеров, очень похожих на эти.

Закрытие в пользу https://github.com/rust-lang/rust/issues/55467.