Bug #407: String#<<

• Status: Closed
• Assignee: naruse (Yui NARUSE)
• Target version: -

[shyouhei (Shyouhei Urabe)]

=begin
以下のようにtrunkの振る舞いは1.8以前と違うのですが、これは1.8
の振る舞いのほうが自然ではないでしょうか? 256が\00になるのは
UTF-8としてもASCII-7BITとしてもなんかおかしい気がします。

% trunk/bin/ruby -Ku -ve'p "ABC" << 256'
ruby 1.9.0 (2008-08-06 revision 17576) [x86_64-linux]
"ABC\x00"
% ruby_1_8/bin/ruby -Ku -ve'p "ABC" << 256'
ruby 1.8.7 (2008-08-06 revision 17572) [x86_64-linux]
-e:1:in `<<': can't convert Fixnum into String (TypeError)
from -e:1
=end

[shyouhei (Shyouhei Urabe)]

• Category set to M17N

=begin

=end

[naruse (Yui NARUSE)]

• Status changed from Open to Closed
• % Done changed from 0 to 100

=begin
Applied in changeset r18399.
=end

[matz (Yukihiro Matsumoto)]

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

このチケットに関連してると思うのですが、

|> % ruby19 -Ku -ve'p "ABC" << 256'
|> ruby 1.9.0 (2008-09-17 revision 19392) [x86_64-freebsd7.1]
|> -e:1:in `': 256 out of char range (RangeError)
|>
|> UTF-8 だとこんな感じ。
|> % ruby19 -Ku -ve's="ABC\u3042" << 256;puts s.dump'
|> ruby 1.9.0 (2008-09-17 revision 19392) [x86_64-freebsd7.1]
|> "ABC\xE3\x81\x82\xC4\x80"
|
|この1.9の振る舞いはうれしくないんじゃないかな。
|"ASCII Compatible"の定義とかをよーく考えると、ASCIIの文字列とそうじゃな
|い文字列はこの場合同じ振る舞いになるべき(黙って大きい方のエンコーディン
|グに揃えるか、一律にエラー)と思いますよ。
|# じゃないと激しく使いづらすぎてかなわん。

という指摘がありました。個人的には現状以外の振る舞いが適切だ
とは思わないのですが、「compatibleなはずなのに振る舞いが違う
のは変」という認知は理解できないでもないです。

=end

[naruse (Yui NARUSE)]

=begin
Yukihiro Matsumoto さんは書きました:

まつもと ゆきひろです

このチケットに関連してると思うのですが、

|> % ruby19 -Ku -ve'p "ABC" << 256'
|> ruby 1.9.0 (2008-09-17 revision 19392) [x86_64-freebsd7.1]
|> -e:1:in `': 256 out of char range (RangeError)
|>
|> UTF-8 だとこんな感じ。
|> % ruby19 -Ku -ve's="ABC\u3042" << 256;puts s.dump'
|> ruby 1.9.0 (2008-09-17 revision 19392) [x86_64-freebsd7.1]
|> "ABC\xE3\x81\x82\xC4\x80"
|
|この1.9の振る舞いはうれしくないんじゃないかな。
|"ASCII Compatible"の定義とかをよーく考えると、ASCIIの文字列とそうじゃな
|い文字列はこの場合同じ振る舞いになるべき(黙って大きい方のエンコーディン
|グに揃えるか、一律にエラー)と思いますよ。
|# じゃないと激しく使いづらすぎてかなわん。

という指摘がありました。個人的には現状以外の振る舞いが適切だ
とは思わないのですが、「compatibleなはずなのに振る舞いが違う
のは変」という認知は理解できないでもないです。

「黙って大きい方のエンコーディングに揃える」、が現在の動きの意図でしょう。

% ruby19 -Ku -e'
p "\u3042" << 0x3044
p "ABCDEF".force_encoding("UTF-8") << 0x3044
p "ABCDEF" << 0x3044'

"あい"
"ABCDEFい"
-e:3:in `': 256 out of char range (RangeError)

しかし、並べてみると確かにこれはおかしな挙動で、
これの原因は思うに ASCII Compatible 云々でなく、
スクリプト内の 7bit clean な String の encoding を US-ASCII にしている点
のような気がします。

=end

[matz (Yukihiro Matsumoto)]

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

In message "Re: [ruby-dev:36399] Re: [Ruby 1.9 - Bug #407] (Open) String#<<"
on Fri, 19 Sep 2008 21:53:10 +0900, "NARUSE, Yui" [e-mail] writes:

|% ruby19 -Ku -e'
|p "\u3042" << 0x3044
|p "ABCDEF".force_encoding("UTF-8") << 0x3044
|p "ABCDEF" << 0x3044'
|
|"あい"
|"ABCDEFい"
|-e:3:in `': 256 out of char range (RangeError)
|
|しかし、並べてみると確かにこれはおかしな挙動で、
|これの原因は思うに ASCII Compatible 云々でなく、
|スクリプト内の 7bit clean な String の encoding を US-ASCII にしている点
|のような気がします。

前からうすうす思っていたのですが、7bitフラグがある以上、わざ
わざUS-ASCIIにする必要はなかったのかもしれませんね。

それはそれとして、この仕様は

• そもそも整数をconcatするのはおかしい
• 1.9では?aはすでに文字列になっている

の二点から考えるに

• 文字列への整数のconcatは禁止
• または0..256の範囲だけ許可(互換性重視)

のいずれかの対応が良いような気がします。

まとめ:

1.9.1直前ですが、以下の二つを提案します。

• 7bit文字列のエンコーディングを特別扱いしない
• String#<<での整数の特別扱いをやめる

=end

[naruse (Yui NARUSE)]

=begin
成瀬です。

Yukihiro Matsumoto さんは書きました:

それはそれとして、この仕様は

• そもそも整数をconcatするのはおかしい
• 1.9では?aはすでに文字列になっている

の二点から考えるに

• 文字列への整数のconcatは禁止
• または0..256の範囲だけ許可(互換性重視)

のいずれかの対応が良いような気がします。

まとめ:

1.9.1直前ですが、以下の二つを提案します。

• 7bit文字列のエンコーディングを特別扱いしない

こちらは賛成です、やっときます。

• String#<<での整数の特別扱いをやめる

確かに「文字列」としての String では String#<<Integer は異様な存在なんで
すが、
「バイト列」や「コードポイント列」として扱う場合には有効な機能なので、
Binarian や Unicoder は困りそうです。
現状、String#setbyte では追加ができませんし、できるようにしたとしても、
str.setbyte(str.length, 0x41) というのもちょっと、なので。

=end

[duerst (Martin Dürst)]

=begin
At 08:00 08/09/20, NARUSE, Yui wrote:

成瀬です。

Yukihiro Matsumoto さんは書きました:

• String#<<での整数の特別扱いをやめる

確かに「文字列」としての String では String#<<Integer は異様な存在なんで
すが、
「バイト列」や「コードポイント列」として扱う場合には有効な機能なので、
Binarian や Unicoder は困りそうです。
現状、String#setbyte では追加ができませんし、できるようにしたとしても、
str.setbyte(str.length, 0x41) というのもちょっと、なので。

成瀬さんと同意です。しばらく残して、様子を見たらどうでしょうか。

宜しくお願いします。 Martin.

#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-# http://www.sw.it.aoyama.ac.jp mailto:[e-mail]

=end

[matz (Yukihiro Matsumoto)]

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

In message "Re: [ruby-dev:36409] Re: [Ruby 1.9 - Bug #407] (Open) String#<<"
on Sat, 20 Sep 2008 16:02:58 +0900, Martin Duerst [e-mail] writes:

|>「バイト列」や「コードポイント列」として扱う場合には有効な機能なので、
|>Binarian や Unicoder は困りそうです。
|>現状、String#setbyte では追加ができませんし、できるようにしたとしても、
|>str.setbyte(str.length, 0x41) というのもちょっと、なので。
|
|成瀬さんと同意です。しばらく残して、様子を見たらどうでしょうか。

まあ、同じような文字列で一方がUS-ASCII、もう一方がUTF-8とい
うようなケースはなくなりましたから、様子を見ましょうか。

=end

[matz (Yukihiro Matsumoto)]

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

In message "Re: [ruby-dev:36416] Re: [Ruby 1.9 - Bug #407] (Open) String#<<"
on Sat, 20 Sep 2008 19:25:30 +0900, Tanaka Akira [e-mail] writes:

|> まあ、同じような文字列で一方がUS-ASCII、もう一方がUTF-8とい
|> うようなケースはなくなりましたから、様子を見ましょうか。
|
|エンコーディングが指定されていないファイルに記述された文字列
|は US-ASCII になるので、問題はむしろわかりにくくなっているよ
|うな気がしますけどねぇ。

US-ASCIIの文字列がまぎれ込むのを禁止できないと言う点では、問
題が解決していないというのは理解できますが、「むしろわかりに
くくなっている」というのはどういうことでしょう。

=end

[matz (Yukihiro Matsumoto)]

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

In message "Re: [ruby-dev:36418] Re: [Ruby 1.9 - Bug #407] (Open) String#<<"
on Sat, 20 Sep 2008 21:02:36 +0900, Tanaka Akira [e-mail] writes:

|中身が ASCII のみの文字列リテラルなら挙動も同じだったのが、
|今では挙動が変化するようになったことを指しています。

うーむ、同じファイルであればエンコーディングが同じという「わ
かりやすさ」を取るか、中身がASCIIのみであればエンコーディング
が同じというわかりやすさを取るか、という対立だと理解すればよ
いでしょうか。

=end

[duerst (Martin Dürst)]

=begin
At 21:53 08/09/19, NARUSE, Yui wrote:

Yukihiro Matsumoto さんは書きました:

まつもと ゆきひろです

このチケットに関連してると思うのですが、

|> % ruby19 -Ku -ve'p "ABC" << 256'
|> ruby 1.9.0 (2008-09-17 revision 19392) [x86_64-freebsd7.1]
|> -e:1:in `': 256 out of char range (RangeError)
|>
|> UTF-8 だとこんな感じ。
|> % ruby19 -Ku -ve's="ABC\u3042" << 256;puts s.dump'
|> ruby 1.9.0 (2008-09-17 revision 19392) [x86_64-freebsd7.1]
|> "ABC\xE3\x81\x82\xC4\x80"

ここは UTF-8 なので、"ABC\u3042\u0100" の方は一般的なユーザに
取ってずっとありがたいかもしれません。

宜しくお願いします。 Martin.

#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-# http://www.sw.it.aoyama.ac.jp mailto:[e-mail]

=end