Go 1.24 で追加された bytes / strings に追加されたイテレータ関数群を試してみる

はじめに

今回は Go 1.24 で bytes / strings に追加されたイテレータ関数群を試してみたいと思います。

Go 1.22 で導入されたイテレータ仕様 (iter.Seq) を活用しており、for-range に直接渡せるようになっています。

従来の Split 系関数が []string を一括で返していたのに対し、1要素ずつ呼び出し元に渡す設計になっているのが主な変更点です。

---

追加された関数一覧

---

そもそも iter.Seq とは

iter.Seq[V] は func(yield func(V) bool) という関数型のエイリアスで Go 1.23 で導入されており、yield に値を渡すことで呼び出し元の for-range ループへ 1件ずつ届ける仕組みになっています。

var seq iter.Seq[string] = func(yield func(string) bool) {
    for _, s := range []string{"a", "b", "c"} {
        if !yield(s) {
            return // yield が false を返したら break された合図
        }
    }
}

for s := range seq {
    fmt.Println(s) // a, b, c
}

break するとイテレータ側の yield が false を返し、処理を止められます。

// yield: "a"
// yield: "b"
// break を検知 → イテレータ終了   ← "c" 以降は yield すら呼ばれない

strings.Lines はこのイテレータ仕様を使い、実際には次のように実装されています。※github - golang

func Lines(s string) iter.Seq[string] {
    return func(yield func(string) bool) {
        for len(s) > 0 {
            var line string
            if i := IndexByte(s, '\n'); i >= 0 {
                line, s = s[:i+1], s[i+1:]
            } else {
                line, s = s, ""
            }
            if !yield(line) {
                return
            }
        }
    }
}

---

strings.Lines と strings.Split の比較

1. 基本的な構文の違い

strings.Split はセパレータ (第 2 引数で指定する区切り文字) を取り除いた各要素を []string として返します。

一方、strings.Lines は改行文字 \n を各行の末尾に含んだまま yield する点が大きな違いです。

s := "apple\nbanana\ncherry"

// 旧: strings.Split — セパレータは除去される
got := strings.Split(s, "\n")
// → ["apple" "banana" "cherry"]

// 新: strings.Lines — 改行文字を含んで yield する
for line := range strings.Lines(s) {
    fmt.Print(line)
}
// → "apple\n" "banana\n" "cherry"

補足: strings.Lines は \n を含んだまま yield しますが、改行文字を除いた値が欲しい場合は strings.TrimRight(line, "\n") で除去できます。

2. 末尾改行の扱いの違い

strings.Split で末尾に \n がある文字列を分割すると、空文字列が末尾に入ってしまいます。テキストファイルの末尾には改行がつくことが多いため、この挙動は意図しないバグを生みやすいです。

s := "first\nsecond\nthird\n"

strings.Split(s, "\n")
// 行数: 4
// 内容: ["first" "second" "third" ""]  ← 末尾に空文字列が入る

strings.Lines はこの問題がありません。末尾の空行は yield されず、得られる行数は直感と一致します。

for line := range strings.Lines(s) { ... }
// 行数: 3
// 内容: ["first\n" "second\n" "third\n"]  ← 空文字列なし

そのため strings.Split で末尾改行を正しく扱うには TrimRight との組み合わせが必要でした。

lines := strings.Split(strings.TrimRight(s, "\n"), "\n")

strings.Lines はこの処理が内部に組み込まれており、呼び出し側で特別な前処理を書く必要がないため、この点は使い勝手が良くなったように思えます。

3. break による早期終了の違い

strings.Split はループ開始前に全行分の []string を一度に確保します。つまり最初の 2 行しか処理しない場合でも、残り全行のメモリは確保済みになります。

strings.Lines はイテレータなので、break した時点で残りの行は yield すら行われません。よって、大きなテキストを部分的に処理したい場合に、無駄なメモリ確保を避けられるようにもなるかと思えます。

s := "line1\nline2\nline3\nline4\nline5\n"

// 旧: strings.Split → ループ前に全行分の []string がすでに確保される
lines := strings.Split(strings.TrimRight(s, "\n"), "\n")
// ループ前に確保済みの行数: 5
// 確保されたが処理しなかった行: [line3 line4 line5]

// 新: strings.Lines → break した時点で残りは yield されない
for line := range strings.Lines(s) {
    if len(processed) == 2 {
        break
    }
}
// 実際に処理した行: [line1 line2]
// line3〜line5 は yield すら行われていない

strings.Lines の主な価値は「必要な分だけ処理できる」点にあります。

全行を処理する場合はどちらを使っても結果は同じですが、早期終了が発生しうるケースでは strings.Lines のほうがメモリ効率で有利なように思えます。

参考

• 末尾改行・break の挙動比較 (gist)

---

strings.FieldsSeq と strings.Fields の比較

空白文字 (スペース・タブ・改行など) を区切りとして分割します。連続した空白はまとめて 1 つの区切りとして扱われるため、先頭・末尾の空白も自動で除かれます。

s := "  foo   bar\tbaz  "

// 旧: strings.Fields — 空白区切りの []string を返す
strings.Fields(s)
// 内容: ["foo" "bar" "baz"]

// 新: strings.FieldsSeq — 空白区切りで 1要素ずつ yield する
for field := range strings.FieldsSeq(s) { ... }
// 内容: ["foo" "bar" "baz"]

連続する区切り文字の扱い

strings.Split は連続した区切り文字の間に空文字列を生成しますが、strings.FieldsSeq は生成しません。これは strings.Fields の従来の挙動を引き継いでいます。

// strings.Split: 連続する区切り文字の間に空文字列が入る
strings.Split("a,,b,,c", ",")
// 要素数: 5  内容: ["a" "" "b" "" "c"]

// strings.FieldsSeq: 連続する空白をまとめて区切るため空文字列なし
strings.FieldsSeq("a  b  c")
// 要素数: 3  内容: ["a" "b" "c"]

strings.Split でセパレータを固定して分割する場合と異なり、strings.FieldsSeq は連続する空白をまとめて 1 つの区切りとして扱うため、余分な空文字列が混入しません。

参考

• strings.Fields - pkg.go.dev
• strings.FieldsSeq - pkg.go.dev
• 連続セパレータの挙動比較 (gist)

---

bytes.SplitSeq と bytes.Split の比較

strings.SplitSeq の []byte 版です。セパレータで分割した各要素を yield します。

結果は bytes.Split と同じですが、[][]byte を事前確保しません。

b := []byte("a,b,c,d")

// 旧: bytes.Split — 全要素の [][]byte を一度に返す
bytes.Split(b, []byte(","))
// 内容: ["a" "b" "c" "d"]

// 新: bytes.SplitSeq — 1要素ずつ yield する
for part := range bytes.SplitSeq(b, []byte(",")) { ... }
// 内容: ["a" "b" "c" "d"]

参考

• bytes.SplitSeq と bytes.Split の挙動比較 (gist)

イテレータ版が有利な場面

イテレータ版は「必要な分だけ処理できる」点が最大の強みのように見えます。

全要素を処理しきる場合は従来の関数とほぼ同等ですが、早期終了が絡むケースではパフォーマンスにそこそこの差が出ると考えられます。

インデックスでランダムアクセスしたい、あるいは要素数を事前に知りたい場合は従来の []string を返す関数が適しています。逆に先頭から順番に処理するだけであれば、イテレータ版を選ぶ理由が十分にあります。

おわりに

Go 1.23 のイテレータ仕様が標準ライブラリに浸透してきた例として、今回の bytes / strings の更新はわかりやすいと思います。

strings.Split の末尾改行問題や TrimRight の必要性など、従来の小さな不便が Lines 系の関数で解消されているのは派手ではないものの実用的な改善だと感じました。

参考

• Go 1.24 Release Notes
• strings package - pkg.go.dev
• bytes package - pkg.go.dev
• iter package - pkg.go.dev
• proposal: spec: add range over func #61405