Unicode文字カテゴリについては、 http://www.fileformat.info/info/unicode/category/index.htmを参照してください。
Haskellは、タイプ「GeneralCategory」と、キャラクターの「GeneralCategory」を決定する関数を実装しています。
それらの実装は次のようになります。
似たようなことをするPythonスクリプトを書くことを提案します。
Rustにこのような型と関数があると、「char」モジュールに関数を正しく実装できます。 http://haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/src/Data-Char.htmlを参照してください
libstdの「unicode ::」と呼ばれる進行中のモジュールは、私がlibicuへのインターフェースをスケッチしようとしていた場所です。 ほとんどのキャラクタークラスにとって、決定は実際にはそれほど単純ではなく、ICUはこれをうまく処理しています。 libicuへの依存関係を採用することで誰もがクールであれば、core :: charで公開できると思いますか?
libicuは多くの追加の望ましい機能を提供し、おそらくほとんどのコンピューターに存在します(Pythonはそれを使用するので、私たちにとっては問題ないはずです)。
パブリックlibicuバインディングを提供しますか、それとも「char」、「str」などのモジュールで内部的に使用しますか?
私は後者に傾倒する傾向があります。
libicuを使用してRustの「char」の関数を正しく実装するには、「u_isspace()」、「u_isdigit()」、「u_forDigit()」(http://icu-project.org/)などの関数を呼び出すだけでよいと思います。 apiref / icu4c / uchar_8h.html)。
完全なlibicuバインディング(多くの定数定義を含む)はまだ必要ありません。
libicuルートに行くべきだと思います。 #1370を参照
これを再開できますか? 私たちはもはやlibicuに依存していませんが、キャラクターのカテゴリーを見つける簡単な方法はまだありません。
非常に古いスレッドについてコメントして申し訳ありませんが、実際にはUCD(v9.0.0)の多くをここに実装しました。 libicuにも標準ライブラリにも依存しないので、プロジェクトで使いやすいはずです(ただし、おそらくICUほど信頼性は高くありません)。
最も参考になるコメント
非常に古いスレッドについてコメントして申し訳ありませんが、実際にはUCD(v9.0.0)の多くをここに実装しました。 libicuにも標準ライブラリにも依存しないので、プロジェクトで使いやすいはずです(ただし、おそらくICUほど信頼性は高くありません)。