[ruby-dev:40868] Re: revert 1.9 \w limitation to ASCII

成瀬です。

2010年3月31日7:09 Yukihiro Matsumoto <[e-mail]>:
> まつもと ゆきひろです
>
> In message "Re: [ruby-dev:40863] Re: revert 1.9 \w limitation to ASCII"
>    on Wed, 31 Mar 2010 02:39:18 +0900, "NARUSE, Yui" <[e-mail]> writes:
>
> |「大きな非互換性になりそうです」というのは何か具体的なフィードバックが
> |背景にあると思っているのですが、どのようなフィードバックでしょうか。
>
> 例によってソースをはっきり覚えていないので恐縮ですが、1.9で
> \wがマッチしなくなったという苦情を見たことがあります。
> Twitterだったかな。

マッチしなくなること自体は予想されたものですが、
どのくらい深刻かというのは難しいところですね。
あと、そもそも期待されていたマッチ対象は何だったのか、とか。

> |次に、Unicode、というか UTF8 に対してのものだと仮定します。ここで、
> |> Unicodeにおいては、キャラクタデータベー
> |> スがあるので、Unicode的にキャラクタなものを対象にするのが良い
> |> と思います。
> |を採用すると、すぐには気づきづらいが実際に問題が出るという、
> |厄介な互換性問題を組み入れることになります。
> |
> |というのも、後に他の言語での \w の中身を出していますが、普通はこの
> |「Unicode的にキャラクタなもの」は記号の類を含みません。
> |ちなみに、Bug #3047 は一足早くそれを期待してがっかりしている例です。
> |http://redmine.ruby-lang.org/issues/show/3047
> |
> |1.9 で \w を「Unicode的にキャラクタなもの」にするとこの逆、
> |具体的には今までマッチしていた一部の文字がマッチしなくなります。
> |これは non ASCII が全てマッチしなくなる (けどすぐに気づく)
> |現在の実装よりたちが悪いのではないでしょうか。
> |つまり、互換性が理由ならばこの案は無いと思うのです。
> |
> |まとめると、互換性が理由ならばエンコーディングに限らず、
> |(とは言っても non dummy encoding になりますが)
> |[a-zA-Z_0-9] + non ASCII (= /[a-zA-Z_0-9\P{ASCII}]/) が正解でしょう。
> |Ruby の文法的にもこれは識別子に使える名前と一致するので意味が
> |なきにしもあらずであるようには思います。
>
> 確かにここは議論の余地のあるところです。
>
> まず、挙動の候補を
>
>  (1) a-zA-Z_0-9
>  (2) a-zA-Z_0-9 + non ASCII
>  (3) Unicode的Caharacter
>
> とします。次に、利用者の立場を
>
>  (a) 1.8スクリプト移植者 (EUC/SJIS)
>  (b) 1.8スクリプト移植者 (UTF-8)
>  (c) EUC/SJIS(要するにUnicode以外)利用者
>  (d) Unicoder
>
> と分けます。これらそれぞれの立場にとって「望ましい」挙動とは
>
>  (a) → (2) : 互換性が維持されるから
>  (b) → (2) : 互換性が維持されるから
>  (c) → (2) : 互換性が維持されるから
>  (d) → (3) : おそらく本来\wに期待するところだから
>
> になるでしょう。(d)以外にとっては、成瀬さんのおっしゃるよう
> に、Unicodeも含めて a-zA-Z_0-9 + non ASCII にすべきという結
> 論になりそうですね。
>
> しかし、今後、Rubyの利用者のうちUnicoderの割合は増加し、互換
> 性を強く期待する人は減少するであろうことを考えると、
>
>  non Unicode → (2)
>  Unicode     → (3)
>
> というのは、さほど悪い選択ではないと思います。一方、現状の
> a-zA-Z_0-9 に限定することは、全員が「しかたない」と感じるもの
> の、多くがうれしくないという「平等に不満」というものになって
> いるのではないでしょうか。

¥d や ¥s、さらには String#upcase などの各種組み込みの挙動が
ASCII ベースの挙動なので、それとの一貫性はうれしいんじゃないでしょうか。

また、識別子としてよくある形式なので、まさにこれが欲しいという例も
それなりにあるでしょう。実際 Ruby の標準添付ライブラリには
それなりに ¥w を利用している例が存在します。

というか、わたしが ¥w を書くときに期待するのは基本的に ASCII の方で、
たまに $KCODE='u' でもそうやってバグを作った方が多かったような。

> 成瀬さんが指摘されるUnicodeにおける互換性問題とは、
>
>  * Unicode利用者、かつ
>  * \w が全てのnon ASCIIキャラクタにマッチすることを期待する
>
> 人に発生するものですが、これの深刻さはちょっとわかりません。
> たいした問題ではなさそうな気もするんだけど。

普通に実装すると、マッチしない例として、[¥〜、。]などなど。
深刻さはユースケースによると思うのですが、¥w のユースケースって
何なのでしょうか。考えた限りでは ¥S の方が適切だったり、数字を除いた方が
良さそうだったり、記号も含めるべきだったりで、いまいち使い道が。

ところで、個人的にマルチバイトの ¥w を使うときって [¥w¥W] で、
マルチバイトの . を作るときだけだったんですが、
普通の方って ¥w を何に使っているのでしょうか。

> |なお、互換性とは別に書きやすさの面で \w で単語構成文字っぽいのに
> |マッチして欲しいという主張ならば別の議論で、以下のような感じになりますか。
> |1. \w だけ特別扱いしたい
> |2. \w だけ Unicode は気持ち悪い
> |2a. [:word:] 使ってよ
> |2b. \d と \s も Unicode 志向に戻そうぜ
>
> ところで、[:word:]って現状なににマッチしますかね。なんとなく、
> a-zA-Z_0-9にしかマッチしないような気がするんですが。[:word:]
> が上で述べた挙動をするのであれば、私の抵抗はだいぶ少なくなる
> んですが。

Perl の ¥w と同じです。つまり、たぶんまつもとさんがイメージしているやつです。
マッチする: 0aA_０ａＡあ漢αЋ
マッチしない: -'@〜、。・¥
http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/trunk/doc/re.rdoc?revision=HEAD&view=markup

以下は特に注のないものは全て Unicode 志向です
* <tt>/[[:alnum:]]/</tt> - Alphabetic and numeric character
* <tt>/[[:alpha:]]/</tt> - Alphabetic character
* <tt>/[[:blank:]]/</tt> - Space or tab
* <tt>/[[:cntrl:]]/</tt> - Control character
* <tt>/[[:digit:]]/</tt> - Digit
* <tt>/[[:graph:]]/</tt> - Non-blank character (excludes spaces, control
  characters, and similar)
* <tt>/[[:lower:]]/</tt> - Lowercase alphabetical character
* <tt>/[[:print:]]/</tt> - Like [:graph:], but includes the space character
* <tt>/[[:punct:]]/</tt> - Punctuation character
* <tt>/[[:space:]]/</tt> - Whitespace character (<tt>[:blank:]</tt>, newline,
   carriage return, etc.)
* <tt>/[[:upper:]]/</tt> - Uppercase alphabetical
* <tt>/[[:xdigit:]]/</tt> - Digit allowed in a hexadecimal number (i.e.,
  0-9a-fA-F)
* <tt>/[[:word:]]/</tt> - A character in one of the following Unicode
  general categories _Letter_, _Mark_, _Number_,
  <i>Connector_Punctuation<i/i>
* <tt>/[[:ascii:]]/</tt> - A character in the ASCII character set

で、これを眺めていると、人々が真に求めているのは実は [:graph:] なんじゃないか
と思ったりするわけです。

-- 
NARUSE, Yui
[e-mail]