Bug #3274: BINARY should not be ASCII-compatible

• Status: Rejected
• Assignee: -
• Target version: -
• ruby -v: -

[yugui (Yuki Sonoda)]

=begin
Yuguiです。

で、おおむねここまでの議論でカバーできていると思うんですが、
Rails びと的には問題を切り分けできていないように思うので、
彼らにはまずデータベースのドライバが適切なものになっているかの確認を
徹底させるのがよいかと思います。
というか、Rails 3 側でドライバのバージョン見た方がいいんじゃないかな。

とりあえずこれでかなり地雷が減ると思うので、データベース周りが綺麗に
なったところで改めて残った問題を見るとよいかと思います。

wycatsと話しまして、railsサイドでのM17N実例からの知見というものを聞き取りました。
それによれば、誤ってBINARYなまま(バイト列のまま)低レベルレイヤーから上がってきた文字列を、文字列リテラル由来の(script
encodingな)文字列と結合した際の互換性エラーが問題で、多数のバグ報告に遭遇しているそうです。

これは第一には、データベースドライバなどレイヤー境界にあるソフトウェアモジュールのバグであるのは確かです。しかしながら、このバグを検出するにあたりBINARYがASCII-compatibleであることが妨げとなっているとのことです。低レベルから上がってくる文字列データが西欧語である場合、バイト列の殆どは0x20-0x7Eです。このため、殆どの場合はエンコーディングがBINARYであるにも関わらずscript
encodingの文字列との結合に成功します。そして、アクセント付き文字のようなものが稀にデータとして出現したときにだけこのバグが発現します。

結局の処、BINARYエンコーディングをASCII-compatibleとして扱うのは英語を処理するアプリケーションを救うにも足りないのみならず、それらのアプリケーションないしそれが依存する低レベルのバグを早期検出するのを疎外しているわけです。

1.9.1リリースから時間を経て、1.9.2リリースも準備段階に入り、この段階に及んで大きな仕様変更とも取れるのは承知ですが、BINARYエンコーディングをASCII
compatibleとしないことを提案します。そもそも、octet
streamを大クラス的に文字列に統合するためのエンコーディングを、script encodingとさえできる状況が異常であったのです。
wycatsから聞いたRails界での実例からは、ドライバのバグに由来する理不尽な例外にアプリケーション開発者が困惑している状況を認識しました。そして、wycatsによれば「この理不尽に見舞われる限りユーザーは1.9に移行しないだろう」と。

何か積極的にBINARYをASCII-compatibleにしておくべき理由がない限り、私はこれをRuby
1.9がまともに使える言語であるための障害と認識し、バグと認定します。
ご意見を伺いたく思います。

--
Yuki Sonoda (Yugui)
[e-mail]
http://yugui.jp
=end

[matz (Yukihiro Matsumoto)]

=begin
まつもと ゆきひろです

In message "Re: [ruby-dev:41278] [BUG:1.9] BINARY should not be ASCII-compatible"
on Tue, 11 May 2010 20:44:41 +0900, Yugui [e-mail] writes:

|1.9.1リリースから時間を経て、1.9.2リリースも準備段階に入り、この段階に及んで大きな仕様変更とも取れるのは承知ですが、BINARYエンコーディングをASCII
|compatibleとしないことを提案します。そもそも、octet
|streamを大クラス的に文字列に統合するためのエンコーディングを、script encodingとさえできる状況が異常であったのです。

BINARYエンコーディングをどうするかについてもう少し教えてくだ
さい。

これは、BINARYエンコーディングとASCII-8BITを分離するというこ
とですか？ それとも分離はせず、ASCII-8BITも含めてASCIIコンパ
チブルにしないという意味でしょうか。

分離する場合、どのようなものがASCII-8BITで、どのようなものが
BINARYなのでしょうか。

分離しない場合、名前的に矛盾するので、ASCII-8BITという名前は
廃止するということでしょうか。その場合、結合が許されないのは
ともかくとしてASCIIの範囲での文字列検索などは可能なのでしょう
か。

また、現状ではlocaleが指定されなかった時やminirubyでは、
Encoding.default_externalが ASCII-8BITになっていますが、これ
は US-ASCII になるのでしょうか。__ENCODING__はどうでしょうか。

|何か積極的にBINARYをASCII-compatibleにしておくべき理由がない限り、私はこれをRuby
|1.9がまともに使える言語であるための障害と認識し、バグと認定します。

実はずっとwycatsの相談に乗っていたのは私ですし、問題意識は理
解できるし、基本的なアイディアには賛成ですが、まずこの「変更」
計画の詳細について聞いておきたいです。

                             まつもと ゆきひろ /:|)

=end

[shyouhei (Shyouhei Urabe)]

=begin
普段、あまりM17Nの件に反応しない卜部ですが、

(2010/05/11 20:44), Yugui wrote:

wycatsと話しまして、railsサイドでのM17N実例からの知見というものを聞き取りました。
それによれば、誤ってBINARYなまま(バイト列のまま)低レベルレイヤーから上がってきた文字列を、文字列リテラル由来の(script
encodingな)文字列と結合した際の互換性エラーが問題で、多数のバグ報告に遭遇しているそうです。

ゴールを確認しましょう。どうせM17Nの問題が魔法のように解決するのはありえませ
ん。Yuguiさんとしてはどうなるのが目標ですか?

• wycatsが黙る
• 低レベルライブラリ作者が黙る
• ユーザーが黙る

おそらくこの三者は排他です。だれに問題を押し付けるかですから。

(snip)

wycatsから聞いたRails界での実例からは、ドライバのバグに由来する理不尽な例外にアプリケーション開発者が困惑している状況を認識しました。そして、wycatsによれば「この理不尽に見舞われる限りユーザーは1.9に移行しないだろう」と。

ユーザーはじゃなくてwycatsは、でしょう。声の大きい人に惑わされてはいけません。

仮にBINARYをASCII incompatibleにすると、既存の拡張ライブラリが生成するありとあ
らゆる文字列がscript encodingと連結不可能になるわけです。これを修正して回るには
相当なマンパワーが必要ですね。拡張ライブラリ作者のなかには「この理不尽に見舞わ
れる限り俺は1.9に移行しない!」って言い出す人、出てくると思いますよ。

んでそのどっちが移行しなくても結局ユーザーから見たら使えないです。

何か積極的にBINARYをASCII-compatibleにしておくべき理由がない限り、私はこれをRuby
1.9がまともに使える言語であるための障害と認識し、バグと認定します。
ご意見を伺いたく思います。

偉い人の仕事には「どっしりと構えて些細なことでは動じない」というのもあると思っ
てます。ASCII compatibilityに関して言えば、俺の理解では誰もがハッピーになる魔法
は存在しないです。どういった落とし所に落ち着いたところで、結局不幸な人は出てく
ると思います。今更振る舞いを変更するコストと不幸の総和は、このままで行く不幸と
どっちが大きいでしょうね?最終的に決めるのは私ではないですが、もし私が決めるとし
たら、現状維持で行くと思います。

=end

[yugui (Yuki Sonoda)]

=begin
2010/5/11 Urabe Shyouhei [e-mail]:

偉い人の仕事には「どっしりと構えて些細なことでは動じない」というのもあると思っ
てます。

偉い人は置いておいて、私はよりよい可能性があればいくらでも軽薄に立場を変えます。
ただ、それが本当によりよいのかについては慎重でありたく、-devで意見を聞きたい訳です。

ゴールを確認しましょう。どうせM17Nの問題が魔法のように解決するのはありえませ
ん。Yuguiさんとしてはどうなるのが目標ですか?
(snip)

• wycatsが黙る
• 低レベルライブラリ作者が黙る
• ユーザーが黙る

誰かが黙る必要もないと思うわけですよ。これまで-talkに流れているように常に、バグを書いてRubyがバグを検出したことについて文句を言う人がいるでしょうから。
一方、低水準ライブラリのバグを高水準の開発者が、事前検出できない程度に低くアプリケーションライフサイクルの中で遭遇する程度には高い確率で踏まされるのは悲劇です。
悲劇を言語が食い止められるならそうあるべきです。

仮にBINARYをASCII incompatibleにすると、既存の拡張ライブラリが生成するありとあ
らゆる文字列がscript encodingと連結不可能になるわけです。

「確率的に連結可能」なのと「連結不能」なのでは連結不能なほうがましだというのが、アプリケーション開発者の悲鳴から思ったことですね。

ただ、

• 低レベルライブラリ作者が黙る
  (snip)
  これを修正して回るには
  相当なマンパワーが必要ですね。拡張ライブラリ作者のなかには「この理不尽に見舞わ
  れる限り俺は1.9に移行しない!」って言い出す人、出てくると思いますよ。

この視点を忘れておりました。それを踏まえて、第一の選択肢としては

ASCII compatibilityに関して言えば、俺の理解では誰もがハッピーになる魔法
は存在しないです。どういった落とし所に落ち着いたところで、結局不幸な人は出てく
ると思います。今更振る舞いを変更するコストと不幸の総和は、このままで行く不幸と
どっちが大きいでしょうね?最終的に決めるのは私ではないですが、もし私が決めるとし
たら、現状維持で行くと思います。

これに賛同します。rb_str_newが生成する文字列はascii-compatibleなままでいきましょう。それでも、もし可能ならば
アプリケーション開発者の悲劇を防ぎたいです。たとえば、ASCII-8BIT(1.8との互換性のためのもの, index
0)とBINARY(octetのためもの)を分離して、
ASCII-8BITは任意のエンコーディングと結合可能で結果はASCII-8BIT、という仕組みなんかはどうでしょうか。

--
Yuki Sonoda (Yugui)
[e-mail]
http://yugui.jp

=end

[nagai (Hidetoshi Nagai)]

=begin
永井＠知能．九工大です．

From: Yugui [e-mail]
Subject: [ruby-dev:41290] Re: [BUG:1.9] BINARY should not be ASCII-compatible
Date: Wed, 12 May 2010 08:42:14 +0900
Message-ID: [e-mail]

ゴールを確認しましょう。どうせM17Nの問題が魔法のように解決するのはありえませ
ん。Yuguiさんとしてはどうなるのが目標ですか?
(snip)

• wycatsが黙る
• 低レベルライブラリ作者が黙る
• ユーザーが黙る

誰かが黙る必要もないと思うわけですよ。これまで-talkに流れているように常に、バグを書いてRubyがバグを検出したことについて文句を言う人がいるでしょうから。
一方、低水準ライブラリのバグを高水準の開発者が、事前検出できない程度に低くアプリケーションライフサイクルの中で遭遇する程度には高い確率で踏まされるのは悲劇です。
悲劇を言語が食い止められるならそうあるべきです。

２年前（と言われて，あぁそんなに前になるのかと思いました (^_^)）の議題の際，
それなりに頑張ってお願いしたつもりですが，
受け入れてもらえずにあきらめて工夫して対処したという経緯はあります．

まぁ，「低レベル」ではないかもしれませんが，
ライブラリ作者が「黙った」例ですよね．

アプリケーション開発者の悲劇を防ぎたいです。たとえば、ASCII-8BIT(1.8との互換性のためのもの, index
0)とBINARY(octetのためもの)を分離して、
ASCII-8BITは任意のエンコーディングと結合可能で結果はASCII-8BIT、という仕組みなんかはどうでしょうか。

こういう仕組みも含めて却下されたのが２年前の議論だと認識しています．
よってライブラリ作者側としては，
「現状が仕様である」として対処しているわけです．

これを変更するのであれば，再び苦労を強いられます．
しかも，互換性維持のために，単純に導入される以上の労力が
求められることになろうかと思います．

つまり，ライブラリ作者側が黙らねばなりません．

この段階で仕様変更しようとするなら，1.9.2 リリースは全くの白紙に戻して
すべての添付ライブラリについての対応チェックが必要となるはずです．
少なくとも Ruby/Tk としては，こんな時期に仕様変更されても
対応することはできないと考えています．

そうまでしても仕様変更しなければならないものなのかを，
２年前の経緯も含めて十分に検討する必要があるはずです．

2.0 に向けての議論であれば反対するつもりはありませんが，
1.9.2 での導入の必要性があると考えて議論するのであれば，
1.9.2 リリース計画を白紙に戻すことを求めます．
期限を限られて済し崩し的に決められてしまうのは納得できません．

1.9.3 での導入を想定しての議論というのもあるでしょうけれど，
そうなると現在の仕様に対応するライブラリ等も増えると考えられ，
悲劇の範囲も拡大するように思います．
それゆえ，1.9.x での仕様変更議論は消極的ながら反対します．

何というか，「何で今さら…」という感じがしています．

--
永井 秀利 ([e-mail])
九州工業大学 大学院情報工学研究院 知能情報工学研究系 知能情報メディア部門

=end

[shyouhei (Shyouhei Urabe)]

=begin
卜部です。

(2010/05/12 8:42), Yugui wrote:

2010/5/11 Urabe Shyouhei [e-mail]:

偉い人の仕事には「どっしりと構えて些細なことでは動じない」というのもあると思っ
てます。

偉い人は置いておいて、私はよりよい可能性があればいくらでも軽薄に立場を変えます。
ただ、それが本当によりよいのかについては慎重でありたく、-devで意見を聞きたい訳です。

誤解を招いていそうなので補足しますと、-devで意見を聞くことは良いことで、そこは
否定してません。また、本当にみんなにとって幸せな解決策が見つかればいいなという
祈りのようなものは私も持っています。

そこで技術的な部分にフォーカスして考えるのですが、

これに賛同します。rb_str_newが生成する文字列はascii-compatibleなままでいきましょう。それでも、もし可能ならば
アプリケーション開発者の悲劇を防ぎたいです。たとえば、ASCII-8BIT(1.8との互換性のためのもの, index
0)とBINARY(octetのためもの)を分離して、
ASCII-8BITは任意のエンコーディングと結合可能で結果はASCII-8BIT、という仕組みなんかはどうでしょうか。

これはたぶんrb_str_newした文字列は新ASCII-8BITになって、それを連結していくと、
非互換な文字列でも黙ってASCII-8BITに汚染されるということかと思いました。すると
既存のライブラリをそのまま動かすと、いつのまにかASCII-8BITな文字列が増えること
が想像できます。それをアプリケーション開発者が避けるにはどうすればいいのかな、
やっぱことあるごとにforce_encodingつけて回るとかでしょうか。アプリケーションは
ちょっと不便になりそうですね。その「ちょっと」が許容できるのなら、ありかなあと
いう気もします。

=end

[naruse (Yui NARUSE)]

=begin
成瀬です。

2010年5月11日20:44 Yugui [e-mail]:

wycatsと話しまして、railsサイドでのM17N実例からの知見というものを聞き取りました。
それによれば、誤ってBINARYなまま(バイト列のまま)低レベルレイヤーから上がってきた文字列を、
文字列リテラル由来の(script encodingな)文字列と結合した際の互換性エラーが問題で、
多数のバグ報告に遭遇しているそうです。

初期に「ASCII-8BIT ってなんだよ」という悲鳴が上がるのは Ruby 自体でも結構ありましたね。

これは第一には、データベースドライバなどレイヤー境界にあるソフトウェアモジュールの
バグであるのは確かです。しかしながら、このバグを検出するにあたりBINARYが
ASCII-compatibleであることが妨げとなっているとのことです。低レベルから上がってくる
文字列データが西欧語である場合、バイト列の殆どは0x20-0x7Eです。このため、殆どの場合は
エンコーディングがBINARYであるにも関わらずscript encodingの文字列との結合に成功します。
そして、アクセント付き文字のようなものが稀にデータとして出現したときにだけこのバグが発現します。

Rails では非 ASCII なケースのユニットテストを書かないんですか?

結局の処、BINARYエンコーディングをASCII-compatibleとして扱うのは英語を処理する
アプリケーションを救うにも足りないのみならず、それらのアプリケーションないし
それが依存する低レベルのバグを早期検出するのを疎外しているわけです。

まぁ、そういう見方はあるでしょう。

1.9.1リリースから時間を経て、1.9.2リリースも準備段階に入り、
この段階に及んで大きな仕様変更とも取れるのは承知ですが、
BINARYエンコーディングをASCII compatibleとしないことを提案します。

wycats が言うのでしたらそのレベルの思いつきでも心情はわかりますが、
yugui さんにはもうちょっと詰めてから仰って欲しいところではあります。

そもそも、octet streamを大クラス的に文字列に統合するためのエンコーディングを、
script encodingとさえできる状況が異常であったのです。

script encoding はこの話の本質とは違いますよね。

wycatsから聞いたRails界での実例からは、ドライバのバグに由来する理不尽な例外に
アプリケーション開発者が困惑している状況を認識しました。そして、wycatsによれば
「この理不尽に見舞われる限りユーザーは1.9に移行しないだろう」と。

これ自体は Rails のアダプタが古いドライバを蹴ればいい話だと思います。

何か積極的にBINARYをASCII-compatibleにしておくべき理由がない限り、私はこれをRuby
1.9がまともに使える言語であるための障害と認識し、バグと認定します。
ご意見を伺いたく思います。

ここまでの問題意識と、よりよい仕様を探っていく姿勢そのものは正しいと思います。
しかし、ここまで荒削りの案をぼちぼち動いている現状をバグ扱いして、
1.9.2 に入れようというのはリリースエンジニアリング的にもおかしいですし、
またあまりに見通しが甘すぎます。rb_str_new の戻り値を ASCII incompatible に
した場合、今年中のリリースすら無理でしょう。

そもそも、現状の Ruby 1.9.2 のリリース時期は 1.9.1 からの乖離や、1.9.1 への固定化を
避ける意味からすると受忍限度の限界で、これ以上遅らせることには全面的に反対です。
また、この変更が互換性を壊すことがそもそもの目的である以上、採用した場合リリース時期への
影響は不可避でしょう。つまり、1.9.2 での変更は有りえないと思います。

この案自体の評価は率直に言って判断できる水準にないと思うので保留します。

--
NARUSE, Yui
[e-mail]

=end

[naruse (Yui NARUSE)]

=begin
成瀬です。

2010年5月12日14:24 Urabe Shyouhei [e-mail]:

卜部です。

(2010/05/12 8:42), Yugui wrote:

2010/5/11 Urabe Shyouhei [e-mail]:

偉い人の仕事には「どっしりと構えて些細なことでは動じない」というのもあると思っ
てます。

偉い人は置いておいて、私はよりよい可能性があればいくらでも軽薄に立場を変えます。
ただ、それが本当によりよいのかについては慎重でありたく、-devで意見を聞きたい訳です。

誤解を招いていそうなので補足しますと、-devで意見を聞くことは良いことで、そこは
否定してません。また、本当にみんなにとって幸せな解決策が見つかればいいなという
祈りのようなものは私も持っています。

そこで技術的な部分にフォーカスして考えるのですが、

これに賛同します。rb_str_newが生成する文字列はascii-compatibleなままでいきましょう。それでも、もし可能ならば
アプリケーション開発者の悲劇を防ぎたいです。たとえば、ASCII-8BIT(1.8との互換性のためのもの, index
0)とBINARY(octetのためもの)を分離して、
ASCII-8BITは任意のエンコーディングと結合可能で結果はASCII-8BIT、という仕組みなんかはどうでしょうか。

これはたぶんrb_str_newした文字列は新ASCII-8BITになって、それを連結していくと、
非互換な文字列でも黙ってASCII-8BITに汚染されるということかと思いました。すると
既存のライブラリをそのまま動かすと、いつのまにかASCII-8BITな文字列が増えること
が想像できます。それをアプリケーション開発者が避けるにはどうすればいいのかな、
やっぱことあるごとにforce_encodingつけて回るとかでしょうか。アプリケーションは
ちょっと不便になりそうですね。その「ちょっと」が許容できるのなら、ありかなあと
いう気もします。

「ASCII-8BIT(1.8との互換性のためのもの, index 0)とBINARY(octetのためもの)を分離して」
はこのケースの場合分離する理由は何でしょう。

また、ASCII-8BIT は任意のエンコーディングと統合可能とした場合、現状出ていた
Encoding::CompatibilityError が出なくなることを意味するのですが、
それって、当初の問題意識である早期検出という観点に置いて、現状より悪化していませんか。

--
NARUSE, Yui
[e-mail]

=end

[yugui (Yuki Sonoda)]

• Status changed from Open to Rejected
• ruby -v set to -

=begin

でも、その解決として ASCII非互換な BINARY という話に飛びつくのは
いかがなものでしょうか。簡単に済む話とは思えません。

そうですね。ちょっと簡単に済みそうにないというのはよく分かりました。
落としどころとして1.9.3あたりに入らないかと思ったんですが、それも難しいですね。そういうわけで、また別の方策を何か考えましょう。
=end

[mame (Yusuke Endoh)]

=begin
遠藤です。

もう reject されたようですが、せっかく書いたので送ります。

2010年5月12日8:42 Yugui [e-mail]:

2010/5/11 Urabe Shyouhei [e-mail]:

偉い人の仕事には「どっしりと構えて些細なことでは動じない」というのもあると思っ
てます。

偉い人は置いておいて、私はよりよい可能性があればいくらでも軽薄に立場を変えます。
ただ、それが本当によりよいのかについては慎重でありたく、-devで意見を聞きたい訳です。

リリースマネージャとしての自覚を持ってください。「よりよい可能性」は
無限にあります。それを妥協・抑制・説得してリリースブランチを安定させる
のがリリースマネージャの仕事です。
リリースマネージャはまつもとさんに次ぐ決定権を持っていますが、その決定
権はリリースを促進するために使ってください。リリースを遅らせるために
使うものではありません。

Yugui さんは rubyspec をパスするために特大の延期をやらかした「前科」が
あります。2 度目をやろうというなら、不信任として解任動議を提案します。
これ以上 1.9.2 に何かを望むのは望みすぎです。いい加減にしてください。

ところで、Yugui さんが暴走した場合に止める役として、リリースマネージャ
補佐をつけるのはどうでしょうか。その場合は私が立候補します。
というか、チケット整理が進んで多少決定権がないと面倒なチケットが残って
きたので、頂けると幸いでもあります。

--
Yusuke Endoh [e-mail]

=end

[yugui (Yuki Sonoda)]

=begin
Yuguiです。

2010/5/12 Yusuke ENDOH [e-mail]:

リリースマネージャとしての自覚を持ってください。「よりよい可能性」は
無限にあります。それを妥協・抑制・説得してリリースブランチを安定させる
のがリリースマネージャの仕事です。

いやはや、これについては返すべき言葉もないです。ちょっと最近血迷ってました。

Yugui さんは rubyspec をパスするために特大の延期をやらかした「前科」が

安定というのは仕様安定性を含めてのことなので、これについては正しい判断であったと確信しますが、一方でこれ以上リリース間隔が延びるのが望ましくないのも明らかですね。

ところで、Yugui さんが暴走した場合に止める役として、リリースマネージャ
補佐をつけるのはどうでしょうか。その場合は私が立候補します。
というか、チケット整理が進んで多少決定権がないと面倒なチケットが残って
きたので、頂けると幸いでもあります。

mameさんはチケットの整理をかなりやってくださってますし、個人的には賛成します。こうして判断能力が鈍ることもありますので。
まつもとさん、いかがですか?

--
Yuki Sonoda (Yugui)
[e-mail]
http://yugui.jp

=end

[matz (Yukihiro Matsumoto)]

=begin
まつもと ゆきひろです

In message "Re: [ruby-dev:41304] Re: [BUG:1.9] BINARY should not be ASCII-compatible"
on Wed, 12 May 2010 22:30:02 +0900, Yugui [e-mail] writes:

|> ところで、Yugui さんが暴走した場合に止める役として、リリースマネージャ
|> 補佐をつけるのはどうでしょうか。その場合は私が立候補します。
|> というか、チケット整理が進んで多少決定権がないと面倒なチケットが残って
|> きたので、頂けると幸いでもあります。
|
|mameさんはチケットの整理をかなりやってくださってますし、個人的には賛成します。こうして判断能力が鈍ることもありますので。

判断能力が鈍るのはお互い様なのですが、まあ、バックアップはあっ
た方がよいですよね。

|まつもとさん、いかがですか?

ということで、賛成します。

=end

[mame (Yusuke Endoh)]

=begin
遠藤です。

2010年5月12日23:36 Yukihiro Matsumoto [e-mail]:

|mameさんはチケットの整理をかなりやってくださってますし、個人的には賛成します。こうして判断能力が鈍ることもありますので。

判断能力が鈍るのはお互い様なのですが、まあ、バックアップはあっ
た方がよいですよね。

言語設計者は判断能力が鈍ったら困りますが、リリースマネージャは
保守的になればいいと思います。迷ったらやらない。

|まつもとさん、いかがですか?

ということで、賛成します。

ありがとうございます。もうちょっと aggressive にチケット整理が
できそうです。

--
Yusuke Endoh [e-mail]

=end