[ruby-dev:38043] Re: ENCODING_FIXED と ENCODING_NONE の廃止

成瀬です。

Tanaka Akira wrote:
> In article <[e-mail]>,
>   "NARUSE, Yui" <[e-mail]> writes:
> 
>> 以上だけなら一見「仕様」にも見えるのですが、
>> このような、Regexp#source.ascii_only? が成立するのに、
>> ASCII 互換なエンコーディングを持つ文字列にマッチさせることができない
>> (Regexp#fixed_encoding? が true な) 正規表現は //u, //s, //e を用いてしか
>> 作ることができないという点です。
> 
> Regexp#source.ascii_only? が成立し、
> Regexp#fixed_encoding? が true 正規表現を
> //u, //s, //e を用いずに作る例はたとえば以下が存在します。
> 
> % ruby -ve '
> r = /\u3042/
> p r.source.ascii_only?
> p r.fixed_encoding?
> '
> ruby 1.9.2dev (2009-02-15 trunk 22328) [i686-linux]
> true
> true

む、確かにエスケープして埋め込んだ場合もそうですね。
すると、Regexp#source.ascii_only? を出したのは不適切でした。

> ここは微妙なところで、正規表現が記述に用いたエンコーディング
> と、それがマッチする対象のエンコーディングには、ちょっとギャッ
> プがあります。ここをいじるには、そのギャップについて充分に考
> える必要があります。

ふむ、一般に言えば確かに仰るとおりです。
\p 等のことも視野に入れれば、十分な検討が必要でしょう。

端的に言えば、その正規表現の記述に用いたエンコーディングと同じ
エンコーディングの文字列の時にマッチできる範囲と、
意味的に概ね同じになるようにしたいですかね。
「概ね」と入れたのは \s や \w、先には \p{Hiragana} 等を考えているわけですが。

> とはいえ、成瀬さんが感じた混乱自体は、なんらかの問題を示して
> いる可能性は充分にあります。
> 
> もう一回、何が問題なのかを正確に表現していただけるとありがた
> いです。

しかし、//u 等に限って言えばそのような大きな問題ではなく、
/a/u と同じことをできる方法が存在せず、UTF-8, EUC-JP, Windows-31J の
3 つのエンコーディングでしか使えない特殊な機能である点から、
局地的な問題だと思っています。

そしてまず、直接的な問題としては、例えば、
> Regexp.new(/a/u.source) == /a/u
=> false
と、Regexp#source と Regexp#new で戻らない点があります。

また、一般に正規表現は一度作ってしまうと、
それがなぜ fixed_encoding なのか後から知ることは困難です。
たいていの場合は
* ASCII 互換エンコーディングでないから
* 正規表現に非 ASCII を示すリテラルまたはエスケープを含むから
* \p 等を含むから
で、これらはそれなりに理由があります。(プロパティ等は将来的に検討が必要でしょう)
しかし //u はそうした正規表現そのものを無視して KCODE_FIXED を付与します。

わたしは //u 記法自体の廃止は主張していないので、これが影響するのは、
/a/u や /\w/u を非 ASCII な文字を含む場合なのでこれらについて考えると、
/a/u は UTF-8 における「a」を他のエンコーディングの「a」と区別し、
UTF-8 のもののみにマッチさせる正規表現と考えられます。
しかし、そのような機能は必要でしょうか。
わたしは必要ないと思いますし、もし必要ならば他のエンコーディングにも提供するべきです。
/\w/u についても同様に感じます。

そして、すでに 1.8 用に書かれた /a/u 等もわざわざ UTF-8 等に限定する意図は
なかったのではないかと思います。
現状、できごころで /u を付けてしまった正規表現リテラルから、
/u を削るという不毛な作業が行われていますが、本当にそれは必要なんでしょうか。
意味論から必要な作業ならば行って貰うべきだと思いますが、
わたしにはそうは思えません。

結局のところ、これは不必要な非対称な機能に見えます。

-- 
NARUSE, Yui  <[e-mail]>