Rust: 非ASCII識別子の追跡の問題（機能 "non_ascii_idents"）

/ cc @ rust-lang / lang

指名

cc @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
cc https://github.com/rust-lang/rust/issues/4928

識別子の正規化とUnicode mod名のファイルシステム名へのマッピング（OS X、IIRC）にも問題がありますが、関連するリンクがここに見つかりません： https ://github.com modとextern crateはASCIIに強制される可能性があります）

はい＃2253は私が知っている大きな問題であり、非Unicode識別子の時期尚早な安定化について心配しています。

（そこでの議論はもっと広く、間違いなく2つのスレッドに分岐する可能性があります。たとえば、識別子用に1つの正規化パスを使用し、文字列リテラルコンテンツ用に別の正規化パスを使用することができます。）

このディスカッションをRFCSリポジトリに移行することをお勧めします（例： https：//github.com/rust-lang/rfcs/issues/802）

私は、これがRFCプロセスを通過するに値する機能であることに同意します。

non_ascii_idents機能ゲートの安定化（または非推奨など）を追跡するために、この問題を再利用しました。

langチーム会議で話し合った後、はい、RFCがここでの適切な方法であると判断しました。 他の言語からソリューションを収集し、それらの長所/短所を分析し、Rustの適切な選択を提案するものが必要です。 これは物議を醸すほど複雑なので、コミュニティ全体に持ち込む必要があります。特に、Rustを日常的にハッキングしている私たちの多くは、非ASCIIの経験があまりないためです。

トリアージ：P-low

現在RFCがないため、実用的なコンテンツがないため、低いマークを付けます。

cc https://github.com/rust-lang/rust/issues/7539

JavaScript、Perl5およびPerl6では、この機能を利用できます。
JavaScript（Firefox 50）

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

Perl> = 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の識別子の価値は、 Unicode Standard Annex＃31のデフォルトの識別子構文に基づいています。

use utf8;のPerlは、以下の正規表現を使用します。 XID_StartとXID_Continue 、おそらくUAX＃31からのものです。

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

はい！ ありがとう@SimonSapin！

Pythonの場合<XID_Start> <XID_Continue>*です。

したがって、非ASCII識別子を許可する多くのプログラミング言語は同じ標準に基づいているように見えますが、詳細では、それぞれがわずかに異なることを行います…

個人的には、数学関連の識別子のサポートを期待しています。 たとえば、∅（および∩や∪などの集合演算子）。 方程式を研究論文/仕様からコードに変換することは、多くの場合、ひどいプロセスであり、冗長で読みにくいコードになります。 論文の数学方程式にあるのと同じ識別子をコードで使用できると、実装が簡素化され、コードを論文の方程式と比較して確認しやすくなります。

この機能の正確なポイントは何ですか？ コード内にさまざまな言語の本当に醜い組み合わせを作成する可能性を追加することを除けば（英語は唯一の真に国際的な言語です）、言語機能に関しては何のメリットもありません。 それとも、UnicodeをサポートするためのUnicodeのサポートですか？

@DoumanAshすべてのプログラムが国際的であるとは限りません。また、英語の流暢さがプログラミングの要件である必要はありません。

コード内の変数名とコメントを英語にすることを決定することは、どのプロジェクトの優れたメンテナでもあります。 これは、rustc自体を含む多くのオープンソースプロジェクトで起こることです。 しかし、それは言語がそれに制限されるべきだという意味ではありません。

私が見ているユースケースは、プロダクションコードを書くためではなく、教えるためのものです。 プログラマーになるには英語に堪能でなければならないことを人々に伝えるのは本当に残念です。 もう1つの状況は、外国語のUIを作成しているときに、UIに「příjmení」というラベルの付いたテキストボックスがあるが、値を「lastname」という名前の変数に入れてしまう場合です。 さらに奇妙なのは、「rodné_číslo」（チェコの国民ID番号）という名前のフィールドがある場合です。 そのための類似した英語の単語はありません。 したがって、チェコの税務アプリや銀行のアプリを作成している場合は、正当な理由もなく奇妙な名前を使用する必要があります。 そのようなアプリはとにかく他の言語に移植できるようなものではありません。

これを可能にするもう1つの理由は、言語学者が変数名にIPA表記を使用する必要がある場合が多いことです。 IPA記号の英語名は、途方もなく長くなる可能性があります。 たとえば、赤という単語のアメリカ英語のr音は、1文字のɹ̠として転写されますが、歯茎後部歯茎後部歯茎の接近音と呼ばれます。 https://en.wikipedia.org/wiki/Alveolar_and_postalveolar_approximantsしたがって、テキストからスピーチへのプログラムを作成している場合は、 fn say_post_alveolar_retroflexive_approximant() fn say_ɹ̠()を記述したいと思うかもしれません。

意見のない面では、どのユニコードコードポイントを変数名の一部にすることができるかに関して、ここで興味深い議論があると思います。 例：変数にprice€という名前を付けることはできますか？ おそらくそうではないでしょう、私はprice$がうまくいくとは思いませんか？ ベクトルを生成するための→！[]マクロを作成できますか？ 誰かがそうしたいと思うかもしれないことは知っていますが、→は「数学記号」 http://www.fileformat.info/info/unicode/char/2192/index.htmです。 したがって、字句解析を行うときは、どのコードポイントが受け入れ可能で、どれが受け入れられないかを決定する必要があります。おそらく、錆は、何かが文字であるかどうかをユニコード標準に単純に尋ねるべきではありません。

現在の実装の@timthelionRustは、Unicode標準に何かが文字であるかどうかを単純に尋ねるのではなく、すべての例で正しく直感的な動作をするXID_StartおよびXID_Continueユニコードプロパティに依存しています。

• $＃ 'ɹ'と'̠'の両方がXID_Continueであるため、 say_ɹ̠が許可されます。
• $＃ '€'と'$'はXID_Continueではないため、 price€とprice$は許可されていません。
• $＃ '→'はXID_Startではないため、$ →![]は許可されていません。
• příjmeníとrodné_čísloが許可されます。

@dtolnay説明ありがとうございます。 私が「ばかげて」という言葉を使ったことに腹を立てていないことを願っています。おそらくそれはあまり選ばれなかった言葉でした。

いいえ、素晴らしい心は同じように考えており、ユニコード技術委員会の優秀な人々はあなたと同じ懸念を持っていたことを指摘するだけです。

他の本番環境のユースケースを考え出すことができます。

特定の分野の一部の単語は英語に翻訳するのが難しいですが、一部のプログラム（ゲーム、ローカルのオンラインからオフラインへのサービスなど）は、中華料理の名前、ヒーローの名前、地名などを処理する必要がある場合があります。 企業で働くプログラマーは、英語の翻訳が何であるかを知る必要はありませんが、変数と関数の名前を付ける必要があります。 彼らが英語を使わなければならない場合、彼らは奇妙な名前を思い付くでしょう、通常他の同僚が理解するのは非常に難しいです。

この時点で、私たちのケースが多いことは間違いないと思います。 やるべきことは、詳細を理解することです。

• 正確にどの文字を許可する必要がありますか。 たとえば、非ASCII句読点はおそらく除外する必要があります。
• 実行する必要のある正規化の量：2つの識別子を異なるコードポイント（ソースファイルでは異なるUTF-8バイト）で表すことができますが、それでも同等と見なされます。

他のいくつかの言語はUnicodeStandardAnnex＃31に同意していますが、詳細にわずかな違いがあります。 理想的には、Rustに最適なものを決定するために、これらの違いの動機を見つけます。

https://rosettacode.org/wiki/Unicode_variable_namesには、多くの言語に関する情報があります。

私は@SimonSapinに同意します-これが役立つことは間違いありません。 問題は、標準的な解決策がなく、私たちの多く（たとえば私自身）がトレードオフを評価するのに不十分な立場にあることです。 私たちに欠けているのは、制約を収集して推奨を行う人だと思います。 この時点では、決定を下さないよりも、決定を下す方が望ましいと思います。ただし、Yet Anotherの一連のルールを採用するよりも、いくつかの先例（理想的には、Unicode仕様または付録、さらには別の言語）に従うことを強く望んでいます。

@nikomatsakisさまざまな言語間の小さな違いの動機を正確に調査するのは良いことですが、誰もその調査を行うためにステップアップせず、とにかく続行したい場合は、UAX＃31に正確に従うと思います（これは私たちの現在の実装は）が適切なデフォルトです。

現在の実装と一致している場合でも、詳細な設計でRFCプロセスを実行する価値がある場合があります。 （使用できる文字、正規化/同等性の比較、将来のUnicodeバージョンの処理方法など）このRFCを作成する人は、少なくとも1回はUAX31を上から下に読むことをお勧めします。

また、識別子用に新しい（または、より可能性が高いのは、既存のプロファイルの1つの制限されたサブセットを使用する）PRECISプロファイル[1]を作成することを検討することもできます。 これにより、わずかに異なる場合でも同じと見なされる識別子を正規化でき（たとえば、同じように見えるテキストを出力するが、Unicode表現がわずかに異なるキーボードを備えたロケールの場合）、明確な情報を提供できます。有効なRust識別子を決定するための簡潔なルールセット。

PRECISフレームワークの既存のRust実装を認識していません（作成に必要なUnicodeインフラストラクチャの多くがまだ不足していると思いますが、これはおそらくいずれかの方法で修正する必要があります）。

私は自分自身を専門家とは呼びませんが、1つの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/

2017年4月11日午後9時1分、SamWhitedは次のように書いています。
>>

また、新しいものを作成することも検討できます（または、より可能性が高いのは、
既存のプロファイルの1つの制限されたサブセット）PRECISプロファイル[1]
識別子用。 これにより、次のような識別子を正規化できます。
わずかに異なっていても同じと見なす必要があります（例：
同じように見えるテキストを出力するキーボードがあるロケールの場合、
ただし、Unicode表現がわずかに異なります）
有効なRustを決定するための明確で簡潔な一連のルール
識別子。

PRECISの既存のRust実装を認識していません
フレームワーク（1つを作成するために必要な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なぜUnicodeのNFCまたはNFKCよりもPRECISなのか？

UnicodeのNFCまたはNFKCよりもPRECISを使用する理由

TL：DR —正規化は、何かが有効な識別子であるかどうかを判断するときに実行したい1つのステップにすぎません。 他の操作も実行する必要がある場合（または実行しない場合があります）。

@SimonSapin Unicodeの正規化はPRECISプロファイルの1つのステップにすぎません（したがって、実際には正規化を使用します。おそらくNFCを推測します）が、PRECISはより広範囲のものをカバーします。 たとえば、正規化フォームは幅のマッピングを行わないため（私は思いませんか？）、 FullWidthはＦｕｌｌＷｉｄｔｈと同じ識別子にはなりません。 全幅のテキストを入力したいキーボードを使用している場合、これは問題になる可能性があります（これは、ラテン文字よりも東アジアの文字の方が問題になる可能性がありますが、全幅のテキストを使用するロケールの誰かが問題になる可能性がありますチャイムを鳴らして、問題を誤って伝えているかどうか教えてください）。 PRECISプロファイルで実行できるその他のことには、許可される文字プロパティのサブセットの定義が含まれます（たとえば、文字、数字、ダッシュ、文字などで始まる）。

_免責事項：_全幅のテキストをマッピングすることが望ましいかどうかについては、実際には考えていません。 これは単なる例です。 正規化が重要なのかもしれませんし、マッピングをまったく気にしないのかもしれません。 Goは、識別子に文字または数字のプロパティがあるかどうかだけをチェックするので、それだけでうまくいくのであれば、私たちにとっても問題ないかもしれません。 確かにもっと考えが必要です。

さらに読む：これはGo仕様が行うことです（これは私が提案したものよりもはるかに単純で、良いことかもしれないし、そうでないかもしれません）： https ://golang.org/ref/spec#Source_code_representation

PRECISを使用するものは何ですか？ プログラミング言語はありますか？

PRECISを使用するものは何ですか？ プログラミング言語はありますか？

どの言語でもわかりませんが、Goはそうします。

関連するGo2の問題：golang / go＃16033

2017年4月11日火曜日02:07:49PM-0700に、SamWhitedは次のように書いています。

たとえば、正規化フォームは幅のマッピングを行わないため、 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それは正しいです。 まあ、実際には提案ではなく、この問題のように考え抜かれるアイデアです（申し訳ありませんが、その文と私のリンクを読み直してください、そしてそれは言葉が不十分でした;それが今それを使用していることを示唆することを意味するのではなく、私だけ非ASCII識別子を処理するためにGo以外が実際に何をするのかわからない）。

@SimonSapin

現在の実装と一致している場合でも、詳細な設計でRFCプロセスを実行する価値がある場合があります。

👍

UAX＃31を読んで、その機能を確認しました。PRECISプロファイルを使用することのもう1つの利点は、stringprepを廃止し、代わりにPRECISを使用するのと同じように、Unicodeバージョン間で将来の互換性とアジャイルを実現する方法を提供します（個々のコードポイント自体ではなく、コードポイントの派生プロパティを操作することによって）。

TR31には、これに対処するための「不変識別子」の概念がありますが、事実上、自由形式クラスから派生したPRECISプロトコルの制限がわずかに少ないバージョンですが、PRECISは、ルールが必要な順序を考慮していません。適用されます（私は思いませんか？）また、ギリシャの最終シグマの使用など、PRECISフレームワークでカバーされるエッジケース、またはハングルジャモ周辺のいくつかのエッジケースもカバーしません（繰り返しますが、私はこれらのどちらの専門家でもありません、しかしそれがPRECISが存在する理由です;専門家はすでに作業を行っています）。

これは、Unicodeバージョン間で将来の互換性とアジャイルを実現する方法を提供します（個々のコードポイント自体ではなく、コードポイントの派生プロパティを操作することにより）。

この点がわかりません。 XID_StartとXID_Continueは派生プロパティです。

この点がわかりません。 XID_StartおよびXID_Continueは派生プロパティです。

その時、私はUAX31を誤解したかもしれません。 特定のUnicodeバージョンが必要なように見えました。 読み直しましたが、どこから入手したのかわかりません。

これを投稿するのに適切な場所かどうかはわかりませんが、数学記号のリンティングでいくつかの興味深い問題が発生する可能性があります。 変数名を書き出すことで簡単に回避できますが、実際の方程式とのより良い相関が目標である場合は重要になる可能性があります。

たとえば、次のスクリーンショットのΔ（大文字）とδ（小文字）。 リンターは/wrong/ではありませんが、ここでスネークケースの要件を適用することは実際には意味がありません。

Swiftのように、XID Start / Continueでなくても、変数名で絵文字を許可することは可能でしょうか？

@fwrs 、絵文字は非絵文字よりもはるかに複雑になりました。

一部のベンダーのおかげで、色や細部を変更し続ける絵文字結合（ZWJ）シーケンスを使用できるようになりました。これらのシーケンスの多くは、必ずしも肉眼では見えません。

また、絵文字の定義は毎年急速に拡大しています。これは、安定した信頼できるニーズを望んでいるシステムレベルのプログラミング言語ではありません。

ですから、かわいいですが、Rustの目標とは相性が悪いと思います。 ただし、錆ベースのスクリプト/教育言語は、目標によっては絵文字を許可することでメリットが得られる場合があります。

@ryankurteこの例には意味上の問題があります。数式を書き写していますが、U +2206INCREMENTではなくU+0394 GREEK CAPITALLETTERDELTAを使用しました。 前者はギリシャ文字の文字であり、ケースマッピングがあります。 後者は数学記号であり、そうではありません。

このコメントをクロスリンクしたい： https ：//github.com/rust-lang/rust/issues/4928#issuecomment -343137316

ここでホモグリフベースの攻撃を有効にする可能性は見ていませんが（誰かがそれらに言及した場合は、ノイズを無視してください）、次のようなコードで警告するリントを要求するために、ちょっとした問題を埋めました：

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

一言で言えば、これら2つのaは異なるUnicode文字であるため、2番目のletバインディングは最初のletバインディングをシャドウイングせず、両方がパスをアサートします（ただし、遊び場はUnicode識別子をサポートしていないようです。これはローカルで試してください;私のために動作します）。

この「機能」を使用して、検出が難しいRustプログラムにエクスプロイトを導入できます。特に、シャドウイングレットバインディングは、私を含め、多くの人が慣用的なRustと見なしているためです。

PS：この「機能」は、手に負えないRustコンテストで役立つかもしれませんが、 #![feature(non_ascii_idents)]は眉をひそめるはずです:)

@gnzlbg人々があなたのセミコロンをギリシャ語の疑問符などに交換するのを防ぐために、紛らわしい検出がすでにある程度サポートされていると思いますが、それが識別子に適用されるかどうかはわかりません。 もしそうなら、それはその問題を解決します。 そうでない場合は、少なくとも、すぐに実行できるツールがあります。

しばらくの間大きな動きがなく、RFCが必要なため、これが閉じられ、コードがコンパイラから削除される可能性があることを少し心配しています。 私は、Rustが21世紀の言語、つまりUnicodeであり、Rustが英語を話さないプログラマーに優しいことをかなり気にかけています。 私に欠けているのは、RFCを実際に作成する機能です。

@ケツバン

人々があなたのセミコロンをギリシャ語の疑問符などに交換するのを防ぐための紛らわしい検出のサポートはすでにあると思いますが、それが識別子に適用されるかどうかはわかりません。

はい、クリップの問題で@ oli-obkが示唆しているように、Rustの実装では、代わりに最新の公式の紛らわしいリストを使用すると思います。

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

ホモグリフベースの攻撃を防ぐことができます。 このリストは同期を保つ必要がありますが、それはビルドシステムの一部として自動化できるものです。

@ケツバン

これを気にするなら、識別子でユニコードをサポートする他の言語があり、これらの言語にはRFCプロセスと同様のプロセスがあります。 あなたはそれらをチェックすることから始めることができます。 誰が知っているでしょう、多分あなたはこの問題のフィードバックと一緒にそれらをマージして、内部フォーラムでpre-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は、それらに非常に類似した例についての_lot_の議論の後、NFKCよりもNFCを明示的に提案しています。

https://github.com/rust-lang/rust/issues/55467を優先して終了します。