2010/5/11 Urabe Shyouhei <shyouhei / ruby-lang.org>:
> 偉い人の仕事には「どっしりと構えて些細なことでは動じない」というのもあると思っ
> てます。

偉い人は置いておいて、私はよりよい可能性があればいくらでも軽薄に立場を変えます。
ただ、それが本当によりよいのかについては慎重でありたく、-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)
yugui / yugui.jp
http://yugui.jp