Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

[インデックス 10101] ファイルの概要

このコミットは、Go言語の標準ライブラリであるbytesパッケージとstringsパッケージにおいて、Unicodeコードポイントを扱う際の型をintからruneに変更するものです。これにより、APIの整合性が向上し、より明確な意図がコードに反映されます。

コミット

commit 8f5718176fdd3040d874f85fbd5c825fbd359173
Author: Russ Cox <rsc@golang.org>
Date:   Tue Oct 25 22:22:09 2011 -0700

    bytes, strings: use rune

    Various rune-based APIs change.

    R=golang-dev, r
    CC=golang-dev
    https://golang.org/cl/5306044

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/8f5718176fdd3040d874f85fbd5c825fbd359173

元コミット内容

このコミットの主な目的は、bytesおよびstringsパッケージ内の様々なAPIで、Unicodeコードポイントを表すためにint型を使用していた箇所をrune型に置き換えることです。これにより、APIのセマンティクスがより明確になり、コードの可読性と保守性が向上します。

変更の背景

Go言語において、文字列はUTF-8エンコードされたバイトのシーケンスとして扱われます。しかし、個々のUnicode文字（コードポイント）を操作する際には、その文字が何バイトで表現されるかに関わらず、単一の論理的な単位として扱いたい場合があります。Goの初期の設計では、このようなUnicodeコードポイントを表現するためにint型が使用されていました。

しかし、int型は汎用的な整数型であり、その用途が多岐にわたるため、コードを読んだ際にそのintが単なる数値なのか、それともUnicodeコードポイントを表しているのかが直感的に分かりにくいという問題がありました。特に、Unicodeの文脈で文字を扱う関数やメソッドにおいて、この曖昧さは混乱を招く可能性がありました。

このコミットは、このような曖昧さを解消し、Unicodeコードポイントを明示的に扱うための専用の型としてruneを導入し、既存のAPIをそれに合わせて変更することで、コードの意図をより明確にすることを目的としています。これにより、開発者はUnicode文字を扱う際に、より安全で意図が明確なコードを書くことができるようになります。

前提知識の解説

Go言語における文字列とUnicode

Go言語の文字列は、不変のバイトスライスであり、通常はUTF-8でエンコードされたテキストを表します。UTF-8は可変長エンコーディングであり、1つのUnicodeコードポイントが1バイトから4バイトで表現されます。

byte型

Go言語のbyte型は、uint8のエイリアスであり、1バイトのデータを表します。これはASCII文字や、UTF-8エンコードされたUnicode文字の個々のバイトを扱う際に使用されます。

rune型

Go言語のrune型は、int32のエイリアスであり、1つのUnicodeコードポイントを表します。これは、UTF-8エンコードされた文字列からデコードされた個々の文字を扱う際に使用されます。rune型を使用することで、開発者はバイトレベルの複雑さを意識することなく、論理的な文字単位で操作を行うことができます。例えば、日本語の漢字や絵文字など、複数バイトで構成される文字もruneとして単一の単位で扱われます。

utf8パッケージ

Go言語の標準ライブラリにはunicode/utf8パッケージが含まれており、UTF-8エンコードされたバイトスライスとruneの間で変換を行うための関数を提供しています。例えば、utf8.DecodeRuneはバイトスライスから次のruneとそのバイト長をデコードし、utf8.EncodeRuneはruneをUTF-8バイトスライスにエンコードします。

技術的詳細

このコミットでは、bytesパッケージとstringsパッケージ内の、Unicodeコードポイントを引数や戻り値として受け取る、あるいは内部で扱う関数やメソッドのシグネチャが変更されています。具体的には、int型で定義されていた引数や戻り値がrune型に変更されています。

例えば、bytes.BufferのWriteRuneメソッドやReadRuneメソッド、bytes.IndexRune、bytes.FieldsFunc、bytes.Mapなどの関数が影響を受けています。同様に、stringsパッケージの対応する関数も変更されています。

この変更は、単に型名をintからruneに置き換えるだけでなく、それに伴う内部的な型変換や、rune型が持つセマンティクスに合わせたロジックの調整も含まれています。例えば、rune型はint32のエイリアスであるため、数値としての比較や演算は引き続き可能ですが、その意図がUnicodeコードポイントであることを明確にすることで、コードの意図がより伝わりやすくなります。

また、テストコードもintからruneへの変更に合わせて修正されており、新しいAPIシグネチャに準拠していることが確認されています。

コアとなるコードの変更箇所

このコミットで変更された主要なファイルと、その中の代表的な変更箇所を以下に示します。

src/pkg/bytes/buffer.go

  • func (b *Buffer) WriteRune(r int) (n int, err os.Error) が func (b *Buffer) WriteRune(r rune) (n int, err os.Error) に変更。
  • func (b *Buffer) ReadRune() (r int, size int, err os.Error) が func (b *Buffer) ReadRune() (r rune, size int, err os.Error) に変更。
  • 内部でint(c)としていた部分がrune(c)に変更。

src/pkg/bytes/bytes.go

  • func IndexRune(s []byte, rune int) int が func IndexRune(s []byte, r rune) int に変更。
  • func FieldsFunc(s []byte, f func(int) bool) [][]byte が func FieldsFunc(s []byte, f func(rune) bool) [][]byte に変更。
  • func Map(mapping func(rune int) int, s []byte) []byte が func Map(mapping func(r rune) rune, s []byte) []byte に変更。
  • func ToUpperSpecial(_case unicode.SpecialCase, s []byte) []byte の内部でMapに渡す無名関数の引数がr intからr runeに変更。
  • func isSeparator(rune int) bool が func isSeparator(r rune) bool に変更。
  • func Runes(s []byte) []int が func Runes(s []byte) []rune に変更。

src/pkg/strings/reader.go

  • func (r *Reader) ReadRune() (rune int, size int, err os.Error) が func (r *Reader) ReadRune() (ch rune, size int, err os.Error) に変更。
  • 内部でint(c)としていた部分がrune(c)に変更。

src/pkg/strings/strings.go

  • func IndexRune(s string, rune int) int が func IndexRune(s string, r rune) int に変更。
  • func FieldsFunc(s string, f func(int) bool) []string が func FieldsFunc(s string, f func(rune) bool) []string に変更。
  • func Map(mapping func(rune int) int, s string) string が func Map(mapping func(rune) rune, s string) string に変更。
  • func ToUpperSpecial(_case unicode.SpecialCase, s string) string の内部でMapに渡す無名関数の引数がr intからr runeに変更。
  • func isSeparator(rune int) bool が func isSeparator(r rune) bool に変更。

これらの変更は、int型でUnicodeコードポイントを扱っていた箇所を、よりセマンティックなrune型に置き換えることで、コードの意図を明確にし、将来的な拡張性や保守性を高めることを目的としています。

コアとなるコードの解説

このコミットの核心は、Go言語のbytesおよびstringsパッケージにおけるUnicodeコードポイントの表現方法を、汎用的なint型から専用のrune型へと統一することにあります。

例えば、bytes.BufferのWriteRuneメソッドを見てみましょう。変更前はfunc (b *Buffer) WriteRune(r int) (n int, err os.Error)でしたが、変更後はfunc (b *Buffer) WriteRune(r rune) (n int, err os.Error)となります。これにより、このメソッドが書き込むのが単なる整数ではなく、Unicodeコードポイントであることが明確になります。

同様に、bytes.IndexRuneのような関数も、検索対象の文字をintではなくruneとして受け取るようになります。これにより、関数シグネチャを見ただけで、その関数がUnicode文字の検索を行うものであることが一目で理解できます。

また、Map関数のように、文字変換を行う高階関数では、引数として渡されるマッピング関数もfunc(rune int) intからfunc(r rune) runeへと変更されます。これは、変換の入力と出力が共にUnicodeコードポイントであることを示し、関数のセマンティクスを強化します。

これらの変更は、Go言語がUnicodeを第一級の市民として扱うという設計思想をより深く反映したものです。rune型を明示的に使用することで、開発者は文字列操作において、バイトレベルの複雑さから解放され、より高レベルな文字単位での思考が可能になります。これにより、多言語対応のアプリケーション開発がより容易になり、潜在的なバグ（例えば、UTF-8のマルチバイト文字を誤って1バイトとして処理してしまうなど）のリスクを低減することができます。

関連リンク

参考にした情報源リンク