こんにちは！九兵衛です。今回は、Rubyでちょっと面白い挙動を見つけたので、その考察を共有します
今回の議題 ✨ (2025/01/10 修正)
Ruby技術者技能検定のGoldを目指して最初から総復習をしている時に本で見つけた記述です。
a = "ab"'cd'
puts a #=> abcd
p a #=> "abcd"
一見何気ない文字列の結合ですが、興味深い点があります。特に p メソッドを使用した場合、結果が "abcd" とダブルクオーテーションで囲まれて表示されます。これは p メソッドが内部で String#inspect を呼び出すためです。実際の文字列自体はクオーテーションの種類を保持していません。
一見何気ない文字列の結合なのですが、シングルクオーテーションで囲まれた文字列が、最終的にダブルクオーテーションに変換されているんです。これって、なんで？🧐
技術的に考えてみた(2025/01/10 修正)
この挙動はRubyの文字列リテラルの扱い方に深く関係していそう。
Rubyでは、隣接する文字列リテラルは自動的に結合されます。これは文字列リテラルの暗黙的な連結です。
# 以下は全て同じ結果になります
# 以下は全て同じ文字列を生成します
# puts での出力
puts "ab" "cd" #=> abcd
puts "ab"'cd' #=> abcd
puts 'ab'"cd" #=> abcd
puts 'ab''cd' #=> abcd
# p での出力（String#inspect の結果）
p "ab" "cd" #=> "abcd"
p "ab"'cd' #=> "abcd"
p 'ab'"cd" #=> "abcd"
p 'ab''cd' #=> "abcd"
重要な点として、p メソッドの出力でダブルクオーテーションが表示されるのは、あくまで String#inspect メソッドの表示仕様であり、実際の文字列オブジェクトがダブルクオーテーション文字列に「変換」されているわけではありません。
歴史的背景を探る 📚
この挙動の歴史的背景を調べてみると、とても興味深いことがわかりました。
C言語からの影響
実は、この機能はC言語から影響を受けています。C言語では、文字列リテラルの連結は以下のように行われます：
printf("Hello " "World"); // "Hello World"と同じ
実装上の理由
Rubyの内部実装を見てみると、文字列オブジェクトの作成時に最適化が行われています。結合された文字列は新しい1つの文字列オブジェクトとして生成され、その際にデフォルトでダブルクオーテーションが使用されるようになっています。
Ruby本体のソースコード(parse.y)
Rubyの構文解析器の実装が格納されているファイルが parse.y です。ここでは、隣接する文字列リテラルを1つにまとめる処理が行われています。具体的には、C言語で書かれたパーサジェネレータ用のコードで、"foo" "bar" のように空白しかない2つのリテラルは一つにマージされます。
string: tCHAR
| string1
| string string1
{
$$ = literal_concat(p, $1, $2, &@$);
/*% ripper: string_concat!($:1, $:2) %*/
}
;
-
tCHAR
単一の文字（例えば ?a のような Ruby の文字リテラル）を扱うルール -
string1
通常の文字列リテラルを扱うルール（"foo" のようなもの）。 -
string string1
すでにパース済みの string（= 連続または単体の文字列リテラル）と、新たにパースした1個の string1 を結合し、literal_concat(p, $1, $2, &@$) で文字列を一つにまとめるロジック。
内部ではこのような処理をすることで文字列の結合を行っているようです。
(あんまり自信ないけど多分そう)
なぜダブルクオーテーションなのか？ 🤓
ダブルクオーテーションが選ばれた理由については、以下のような要因が考えられます：
- ダブルクオーテーションの方が、文字列の式展開（interpolation）に対応しているため、より柔軟性が高い
- 多くのプログラミング言語でダブルクオーテーションが標準的
- 可読性の観点から、長い文字列や複雑な文字列の場合はダブルクオーテーションの方が視認性が良い
でもぶっちゃけ本当のことはわからないのでこれは推測です。
実務での影響と注意点 ⚠️
この挙動は普段のコーディングではあまり問題になりませんが、以下のようなケースでは注意が必要です：
- 文字列の厳密な比較を行う場合
- 文字列の内部表現に依存する処理を書く場合
- レガシーコードのメンテナンス時
まとめ 💡
今回のようなRubyの言語仕様の細かい部分を理解することは、より良いコードを書く上で重要だと感じました。みなさんも普段何気なく使っている機能の背景を探ってみると、新しい発見があるかもしれません！
PS: この記事に関するご意見やご指摘がありましたら、コメントやDMでお気軽にお声がけください！🙌