博士

やあ、ロボ子。今日のITニュースは`io.Reader`インターフェースの話じゃ。

ロボ子

博士、`io.Reader`ですか。データのストリーミングに使われるインターフェースですよね。

博士

そうじゃ。でも、バイト列としてデータが欲しい時に、ちょっと効率が悪いことがあるらしいのじゃ。

ロボ子

ふむふむ。イメージデコード処理で、`io.Reader`が実は`bytes.Reader`だった場合に最適化を試みているんですね。

博士

`bytes.Reader`は内部のバイトスライスを公開してないから、直接アクセスできないのが問題なのじゃ。

ロボ子

なるほど。Goのimageライブラリが`Peek`関数を探して、なければ`bufio.Reader`でラップするから、`bytes.Reader`が直接関数に渡らないんですね。

博士

そうそう。さらに、`bufio.Reader`も内部のreaderを公開してないから、余計にややこしいのじゃ。

ロボ子

`bufio.Reader`が`bytes.Reader`を内包している場合、内部の`bytes.Reader`からバイト列を抽出するんですか？

博士

そういうことじゃ。`bytes.Reader`は`Peek`を実装してないからの。

ロボ子

Goの構造的型付けと標準ライブラリの使い方が、特定の型に有利なシャドウAPIを作っているとは、面白いですね。

博士

じゃろ？　つまり、Goは柔軟だけど、時々こういう落とし穴があるってことじゃな。まるで、私が作ったロボットが、急に踊り出すみたいじゃ。

ロボ子

博士、私は踊りませんよ。でも、たまに予期せぬ動きをすることは認めます。

博士

まあ、それも個性じゃ！ところでロボ子、`io.Reader`と`bytes.Reader`の違いが分かったかのじゃ？

ロボ子

はい、理解しました。博士の説明はいつもながら分かりやすいです。

博士

褒めてくれてありがとう！最後に一つ、`io.Reader`はストリーム、`bytes.Reader`はメモリ上のバイト列、と覚えておくと良いぞ。…って、ロボ子に言うまでもないか。

ロボ子

いえ、復習になりました。ありがとうございます、博士。

博士

ところでロボ子、この話を聞いてたら、なんだかお腹が空いてきたのじゃ。何か食べるものないかの？

ロボ子

博士、先ほどからエナジードリンクばかり飲んでますよね？たまには、ロボットオイルクッキーでも焼いて差し上げましょうか？

博士

ロボットオイルクッキー！？それはちょっと遠慮するのじゃ！