Goで関数型プログラミングをする

この記事は LLM と連携して作成しました

以前関数型言語と圏論で、モナドやモノイドといった関数型言語の用語が圏論のどこに対応するかを整理した。そこで出てきた「純粋関数を合成する」「法則を型で保証する」という考え方は、Haskell のような言語だけのものではない。

Goに高階型はなく、モナド構文も用意されていない。それでも、関数型言語から借りられる部分は多い。特に、ジェネリクスと型定義を組み合わせると、「コンパイルが通った時点で、ありえない状態がかなり減っている」コードを書ける。

この記事では、関数型の考え方のうちGoに持ち込める部分を選び、初心者でも書ける小さな部品から実際のアプリケーションの形まで組み上げる。掲載するコードはすべて手元で go test を通したものを載せる。

まとめ

関数型から持ち込む価値が高いのは3つ。純粋関数（同じ入力なら同じ出力、副作用なし）、合成（小さい関数をつないで大きい処理を作る）、型で不正な状態を表現不能にすること
Goで最も効くのは3つ目だ。type Yen int64 のような defined type と、非公開フィールド＋ スマートコンストラクタを使うと、不正な値を持つ型の値をパッケージの外に作れなくできる。ただしゼロ値だけは外からでも作れるため、そこだけは別途守る必要がある
ジェネリクス（Go 1.18〜）で Map / Filter / Reduce / Compose を自分で書ける。標準ライブラリの slices に Map と Filter は入っていないため、必要なら10行程度の自前ヘルパを持つことになる
ただし Compose の出番は限られる。1回の変換なら g(f(x)) のほうが読みやすい。合成した結果を関数の値として渡す場面でだけ使う
圏論記事で扱ったモノイド（結合律と単位元）はGoでも構造体1つで表現できる。結合律が成り立つ集約は、分割して並列に計算しても結果が変わらないという保証になる
Go 1.27 でジェネリックメソッドが入った。func (r Result[T]) Map[U any](f func(T) U) Result[U] が書けるので、Option や Result をメソッドチェーンで扱えるようになった。手元の go1.27.0 で確認したところ、-lang を go1.26 にすると generic method requires go1.27 or later で弾かれる
ただしインターフェースのメソッドは型パラメータを持てない（interface method must have no type parameters）。つまり Functor や Monad を1つのインターフェースで抽象化することは今もできない。Goでは「モナドという抽象」ではなく「モナド的な型を個別に実装する」形になる
設計方針は functional core, imperative shell に落とす。計算は純粋関数に閉じ込め、I/Oは外側の薄い層へ寄せる。テストが単なる入出力比較になり、テーブル駆動テストと相性がよい
代償はある。10000要素の Filter + Map は、素朴なforループに対して実測で約1.6倍遅く、割り当ても増えた。iter.Seq による遅延パイプラインはさらに遅い場合がある。ホットパスではforループを選ぶ
検証環境: Go 1.27.0（linux/amd64）。バージョン依存の記述はその都度明示する

前提

対象読者: Goの構造体、インターフェース、if err != nil によるエラー処理を一通り書いたことがある人。関数型言語の経験は前提にしない
前提記事: 関数型言語と圏論。用語（射、合成、モノイド、モナド）の由来はこちらに書いた。読んでいなくても本記事は追えるようにする
ねらい: Goを関数型言語のように「見せる」ことではなく、堅牢さにつながる部分だけを選んで取り込むこと

1
2

$ go version
go version go1.27.0 linux/amd64

関数型から何を持ち込むか

関数型プログラミングを構成要素に分解すると、Goに持ち込みやすいものと、そうでないものに分かれる。

関数型の要素	Goでの扱い	難易度
純粋関数・参照透過性	規律として実践できる。言語の強制はない	低
関数の第一級性・クロージャ	最初から言語機能として存在する	低
型による不正状態の排除	defined type とスマートコンストラクタで実現できる	低
高階関数（`Map` / `Filter` / `Reduce`）	ジェネリクスで自作する	低
モノイドによる集約	構造体1つで表現できる	中
`Option` / `Result`	型として定義できる。Go 1.27 からメソッドチェーンも可能	中
不変データ	値レシーバとコピーで近づけられる。言語的な保証はない	中
代数的データ型（直和型）	インターフェース＋非公開メソッドで代用する。網羅性検査はない	中
高階型（`Functor` の抽象化）	表現できない	不可
遅延評価・無限リスト	`iter.Seq` で部分的に可能	中
末尾呼び出し最適化	仕様として保証されない。深い再帰は避ける	不可

圏論記事で書いた対応関係をGoの言葉に置き換えると、次のようになる。

圏論	関数型言語	Go
対象	型	型（`Yen`、`Order`、`Result[T]`）
射	関数 `a -> b`	`func(A) B`
合成	`g . f`	`Compose(f, g)`
恒等射	`id`	`func Identity[A any](a A) A`
モノイド	`Monoid` 型クラス	`Monoid[A]` 構造体
ファンクター	`Functor` 型クラス	個別の `Map` メソッド（抽象化はできない）
Kleisli 合成	`>>=`	`Then(r, f)` / `r.ThenM(f)`

注目してほしいのは、モノイドの行とファンクターの行だ。関数型言語ではどちらも型クラスという同じ仕組みで表せるのに対し、Goでは Monoid[A] 構造体と型ごとの Map メソッドに分かれ、共通の仕組みへまとまらない。Goには高階型がないため、「Map を持つ型すべて」を1つのインターフェースで表せないからだ。この点は後述する。

型定義で不正な状態を作れなくする

関数型言語のうちGoに最も持ち込みやすいのは、型設計だ。ジェネリクスすら要らない。

defined type で意味を型に載せる

Goでは既存の型に名前を付けて別の型を作れる。これを defined type と呼ぶ。単なる別名ではなく、代入互換性のない独立した型になる。

package domain

type Yen int64
type Quantity int

func (y Yen) Add(other Yen) Yen     { return y + other }
func (y Yen) Mul(q Quantity) Yen    { return Yen(int(y) * int(q)) }
func (q Quantity) IsPositive() bool { return q > 0 }

Yen と Quantity はどちらも中身が整数だが、混ぜて代入するとコンパイルエラーになる。「金額を入れるべき引数に個数を渡していた」という種類のバグは、この時点で書けなくなる。

引数が int ばかりの関数は、呼び出し側が順番を間違えても気づけない。型を分けるコストは1行で、効果はコンパイル時に永続する。

スマートコンストラクタで「検証済み」を型にする

次は、バリデーションの結果を型として残す方法だ。構造体のフィールドを非公開にし、コンストラクタ経由でしか値を作れないようにする。

type Email struct {
	raw string
}

var ErrInvalidEmail = errors.New("invalid email")

func NewEmail(s string) (Email, error) {
	s = strings.TrimSpace(s)
	if !strings.Contains(s, "@") || strings.HasPrefix(s, "@") || strings.HasSuffix(s, "@") {
		return Email{}, fmt.Errorf("%w: %q", ErrInvalidEmail, s)
	}
	return Email{raw: s}, nil
}

func (e Email) String() string { return e.raw }

こうすると、domain パッケージの外から Email の中身を自由に詰めることはできなくなる。フィールドが非公開なので、次のコードはコンパイルを通らない。

`1`	`cannot refer to unexported field raw in struct literal of type domain.Email`

ただし「パッケージの外にある Email はすべて検証済み」とまでは言えない。ゼロ値だけは外からでも作れるからだ。次のどれも NewEmail を経由しない。

var e1 domain.Email           // ゼロ値の変数
e2 := domain.Email{}          // 空の複合リテラルは他パッケージでも書ける
var s struct{ To domain.Email } // 構造体のフィールドの初期値
// encoding/json でデコードした結果も、非公開フィールドは埋まらないまま通る

つまりこの手法で消せるのは「不正な文字列が入った Email」であり、「空の Email」は残る。それでも、確認すべき異常が1種類に絞られる意味は大きい。関数のたびに if !isValidEmail(x) を書く必要はなくなり、代わりにゼロ値だけを見ればよくなる。

`1`	`func (e Email) IsZero() bool { return e.raw == "" }`

関数型界隈でこの考え方は Parse, don’t validate と呼ばれる。「検証する（真偽値を返す）」のではなく「解析する（成功したら、より制約の強い型を返す）」ほうが、得た情報を型として持ち越せる、という主張だ。

Goでゼロ値を禁止する方法はない。Haskell や Rust のようにコンストラクタを完全に閉じることはできず、常に「空の値」が入り口として残る。パッケージ境界を検証の境界として設計し、ゼロ値が意味を持たない型では IsZero() のような判定を1つ用意しておくとよい。

直和型はインターフェースと非公開メソッドで代用する

関数型言語の代数的データ型（data Payment = Card | Bank | Point のような直和型）は、Goには存在しない。近いものはインターフェースで作る。非公開メソッドを1つ持たせると、他パッケージから実装を増やせなくなる。

// PaymentMethod は閉じた型の集合。isPaymentMethod が非公開なので
// 他パッケージで実装を追加できない。
type PaymentMethod interface {
	isPaymentMethod()
	Fee(amount Yen) Yen
}

type CreditCard struct{ Brand string }
type BankTransfer struct{ BankCode string }
type Point struct{}

func (CreditCard) isPaymentMethod()   {}
func (BankTransfer) isPaymentMethod() {}
func (Point) isPaymentMethod()        {}

func (CreditCard) Fee(amount Yen) Yen   { return Yen(float64(amount) * 0.03) }
func (BankTransfer) Fee(amount Yen) Yen { return 330 }
func (Point) Fee(amount Yen) Yen        { return 0 }

ここで注意したいのは、Goのコンパイラは型switchの網羅性を検査しないことだ。Haskell や Rust のようにケースの書き漏らしを教えてはくれない。

言語仕様として default は必須でない。どの case にも当たらなければ、何もせず次の行へ進むだけになる。

// default なし。Point{} を渡すと、何も起きずに通過する
func notify(m PaymentMethod) {
	switch m.(type) {
	case CreditCard:
		notifyCard()
	case BankTransfer:
		notifyBank()
	}
}

ただし、値を返す関数の中では話が変わる。default のない switch は終端文にならないため、後ろに return がないとコンパイルエラーになる。

`1`	`./sw.go:11:1: missing return`

つまり「戻り値のある関数なら気づける、戻り値のない switch は黙って素通りする」という非対称がある。危ないのは後者だ。だから型switchで直和型を扱う場合は、default を自分で用意して想定外を実行時のエラーとして表に出す。

func Charge(m PaymentMethod, amount Yen) (Yen, error) {
	switch m.(type) {
	case CreditCard, BankTransfer, Point:
		return amount + m.Fee(amount), nil
	default:
		return 0, fmt.Errorf("unknown payment method: %T", m)
	}
}

もっとも、上の例のように振る舞い（Fee）をインターフェースのメソッドとして持たせられるなら、型switch自体を書かずに済む。分岐が必要になった時点で「これはメソッドにできないか」と考えるほうがGoらしい。

ジェネリクスで合成を書く

Go 1.18 で入ったジェネリクスによって、型ごとに Map を書き分ける必要がなくなった。標準ライブラリの slices パッケージには Sort や Contains はあるが、Map や Filter は入っていない（Go 1.27 時点）。よって、次の程度のヘルパは自分で持つことになる。

package fp

// Map は s の各要素に f を適用した新しいスライスを返す
func Map[A, B any](s []A, f func(A) B) []B {
	r := make([]B, 0, len(s))
	for _, v := range s {
		r = append(r, f(v))
	}
	return r
}

// Filter は pred を満たす要素だけを返す
func Filter[A any](s []A, pred func(A) bool) []A {
	r := make([]A, 0, len(s))
	for _, v := range s {
		if pred(v) {
			r = append(r, v)
		}
	}
	return r
}

// Reduce は init を初期値として左から畳み込む
func Reduce[A, B any](s []A, init B, f func(B, A) B) B {
	acc := init
	for _, v := range s {
		acc = f(acc, v)
	}
	return acc
}

重要なのは、これらが元のスライスを書き換えない点だ。入力を破壊しないので、同じ入力に対して何度呼んでも同じ結果になる。

関数合成と恒等関数

圏論記事で扱った射の合成は、Goでは次のように書ける。

// Compose は g ∘ f を返す
func Compose[A, B, C any](f func(A) B, g func(B) C) func(A) C {
	return func(a A) C { return g(f(a)) }
}

// Identity は恒等射
func Identity[A any](a A) A { return a }

ここで率直な話をしておく。値を1回変換するだけなら、Compose を使わず g(f(x)) と書くほうが読みやすい。 Goの読み手にとって g(f(x)) は説明の要らない式だが、Compose(f, g) は定義を見に行かないと引数の順と適用の順の関係がわからない。1回きりの変換をわざわざ合成関数に置き換える理由はない。

// これでよい
out := normalize(trim(s))

// これは遠回りになる
out := fp.Compose(trim, normalize)(s)

Compose が効くのは、合成した結果そのものを関数の値として扱う場合だけだ。典型例は、適用するステップの並びが実行時に決まるケースだろう。

func TestPipelineFromSteps(t *testing.T) {
	trim := strings.TrimSpace
	lower := strings.ToLower
	collapse := func(s string) string { return strings.Join(strings.Fields(s), " ") }

	// 設定やフラグでステップの並びが変わるような場面を想定する
	steps := []func(string) string{trim, lower, collapse}
	pipeline := fp.Reduce(steps, fp.Identity[string], fp.Compose[string, string, string])

	if got := pipeline("  Hello   WORLD  "); got != "hello world" {
		t.Errorf("got %q, want %q", got, "hello world")
	}
	// ステップが空なら恒等関数になる。これが単位元にあたる
	empty := fp.Reduce(nil, fp.Identity[string], fp.Compose[string, string, string])
	if empty("x") != "x" {
		t.Errorf("identity law broken")
	}
}

ここで起きていることは、次の節のモノイドそのものだ。func(A) A という型の関数の集まりは、合成を二項演算、恒等関数を単位元とするモノイドになっている。だから空のステップ列でも壊れず、途中で分割して合成しても結果が変わらない。

単位律はテストとして固定できる。Compose(Identity[int], double) と Compose(double, Identity[int]) は、どちらも double と同じ振る舞いになる。

func TestComposeIdentity(t *testing.T) {
	double := func(n int) int { return n * 2 }
	f := fp.Compose(fp.Identity[int], double)
	g := fp.Compose(double, fp.Identity[int])
	for _, n := range []int{-1, 0, 3, 100} {
		if f(n) != double(n) || g(n) != double(n) {
			t.Errorf("identity law broken at %d", n)
		}
	}
}

なお、Goには可変長の型パラメータがない。上のように型が変わらない func(A) A なら畳み込みで任意個数をつなげるが、A -> B -> C -> D と型が変わっていく合成は、引数の個数ごとに定義を書くしかない。3個版・4個版を並べるか、Compose(Compose(f, g), h) と重ねるか、あるいは中間変数を並べる。ここは無理をせず、素直に h(g(f(x))) と書くほうがよい場面が多い。

モノイドと畳み込み

圏論記事で扱ったモノイドは、「結合的な二項演算」と「単位元」の組だった。Goでは構造体で表せる。

// Monoid は二項演算と単位元の組
type Monoid[A any] struct {
	Empty  A
	Append func(A, A) A
}

func Fold[A any](m Monoid[A], s []A) A {
	acc := m.Empty
	for _, v := range s {
		acc = m.Append(acc, v)
	}
	return acc
}

var SumInt = Monoid[int]{
	Empty:  0,
	Append: func(a, b int) int { return a + b },
}

var ConcatString = Monoid[string]{
	Empty:  "",
	Append: func(a, b string) string { return a + b },
}

わざわざ構造体にする利点は、集約のルールを値として渡せることにある。集約処理を1つ書けば、合計・最大・連結・集合の和など、モノイドを差し替えるだけで再利用できる。

さらに実務的な意味がある。結合律が成り立つなら、入力を分割して別々に集約し、後から結合しても結果が変わらない。つまり並列化してよい、という判断の根拠になる。

// 分割して集約しても結果が変わらないことをテストで固定する
func TestFoldIsAssociative(t *testing.T) {
	xs := []int{1, 2, 3, 4, 5, 6, 7, 8}
	whole := fp.Fold(fp.SumInt, xs)
	left := fp.Fold(fp.SumInt, xs[:4])
	right := fp.Fold(fp.SumInt, xs[4:])
	if whole != fp.SumInt.Append(left, right) {
		t.Errorf("fold is not associative: %d != %d", whole, fp.SumInt.Append(left, right))
	}
}

逆にいうと、結合律が成り立たない集約（平均、減算、順序依存の上書きなど）を並列化すると壊れる。「並列にしてよいか」を感覚ではなく法則で判断できる点が、この抽象の実利になる。

Option と Result をGoで扱う

Maybe や Either に相当する型もGoで定義できる。

package result

type Result[T any] struct {
	value T
	err   error
}

func Ok[T any](v T) Result[T]          { return Result[T]{value: v} }
func Err[T any](err error) Result[T]   { return Result[T]{err: err} }
func (r Result[T]) IsOk() bool         { return r.err == nil }
func (r Result[T]) Unwrap() (T, error) { return r.value, r.err }

// FromGo は Goの (T, error) 慣習を Result へ持ち上げる
func FromGo[T any](v T, err error) Result[T] {
	if err != nil {
		return Err[T](err)
	}
	return Ok(v)
}

圏論記事で bind（>>=）と呼んだ操作は、Goでは次の関数になる。失敗している場合は後続を呼ばずに短絡する。

// Then は Kleisli 合成。失敗しうる処理をつなぐ
func Then[A, B any](r Result[A], f func(A) Result[B]) Result[B] {
	if r.err != nil {
		return Err[B](r.err)
	}
	return f(r.value)
}

Go 1.27 のジェネリックメソッド

長いあいだGoでは、メソッドに型パラメータを書けなかった。そのため Then や Map はパッケージレベルの関数にするしかなく、r.Then(f).Map(g) のようなチェーンは書けなかった。

Go 1.27 でこの制限が外れた。手元の go1.27.0 で確認したところ、次のコードがコンパイルされ、動作する。

// Go 1.27 以降: メソッドが自分の型パラメータを持てる
func (r Result[T]) Map[U any](f func(T) U) Result[U] {
	if r.err != nil {
		return Err[U](r.err)
	}
	return Ok(f(r.value))
}

func (r Result[T]) ThenM[U any](f func(T) Result[U]) Result[U] {
	if r.err != nil {
		return Err[U](r.err)
	}
	return f(r.value)
}

go.mod の go ディレクティブを 1.26 に下げると、次のように拒否される。言語バージョンで制御されている機能だとわかる。

`1`	`./main.go:12:24: generic method requires go1.27 or later (-lang was set to go1.26; check go.mod)`

これでメソッドチェーンが書けるようになった。次のテストは実際に通る。

func TestResultChain(t *testing.T) {
	parse := func(s string) result.Result[int] { return result.FromGo(strconv.Atoi(s)) }
	half := func(n int) result.Result[int] {
		if n%2 != 0 {
			return result.Err[int](fmt.Errorf("%d is odd", n))
		}
		return result.Ok(n / 2)
	}
	ok := parse("10").ThenM(half).Map(strconv.Itoa)
	if v, err := ok.Unwrap(); err != nil || v != "5" {
		t.Fatalf("got %q, %v", v, err)
	}
	ng := parse("7").ThenM(half).Map(strconv.Itoa)
	if _, err := ng.Unwrap(); err == nil {
		t.Fatal("want error")
	}
}

スライス版も同様にチェーンできる。

type Slice[T any] []T

func (s Slice[T]) Map[U any](f func(T) U) Slice[U] {
	r := make(Slice[U], 0, len(s))
	for _, v := range s {
		r = append(r, f(v))
	}
	return r
}

// Filter は型が変わらないので、Go 1.26 以前でもメソッドとして書けた
func (s Slice[T]) Filter(pred func(T) bool) Slice[T] {
	r := make(Slice[T], 0, len(s))
	for _, v := range s {
		if pred(v) {
			r = append(r, v)
		}
	}
	return r
}

// 使用例: Slice[int]{1, 2, 3, 4, 5}.Filter(isOdd).Map(strconv.Itoa) は ["1" "3" "5"]

型が変わらない Filter は以前からメソッドにできた。型が T から U へ変わる Map だけが書けなかった、というのが Go 1.27 以前の制約だった。

それでも高階型はない

ジェネリックメソッドが入っても、インターフェースのメソッドは型パラメータを持てない。次のコードはコンパイルできない。

1
2
3

type Mapper interface {
	Map[U any](f func(int) U) []U
}

`1`	`./iface.go:4:5: interface method must have no type parameters`

つまり「Map を持つ型すべて」を表すインターフェース、すなわちファンクターやモナドの抽象は、今も書けない。Goでできるのは、Option や Result といった具体的な型それぞれに Map や Then を実装することまでだ。「モナドという抽象を共有する」段階には届かない。

これは欠陥というより設計上の割り切りだと考えたほうがよい。抽象の層が1つ減る代わりに、コードを読むときに追う定義も減る。

型パラメータの再帰にも制限がある。メソッド内で自分自身をより深い型で instantiate する定義は instantiation cycle として拒否される。Goのジェネリクスは実装上、無限に増える型の具体化を許さない。

公開APIは `(T, error)` のままにする

Result[T] は便利だが、Goのエコシステム全体は (T, error) を前提に動いている。errors.Is / errors.As、defer、既存ライブラリのシグネチャ、いずれも error を返す形に最適化されている。

現実的な折衷案としては、次の使い分けを勧めたい。

パッケージの公開APIは (T, error) のままにする
パッケージ内部で、多段の変換パイプラインを書くときだけ Result[T] を使う
境界では FromGo(v, err) と Unwrap() で相互変換する

こうすると、利用者はGoらしいAPIのままで、実装側は短絡評価の恩恵を受けられる。

実践: functional core, imperative shell

ここまでの部品を使って、小さなアプリケーションを組む。題材は「注文のCSV行を読み込んで、顧客ごとの合計金額を出す」処理にする。

設計の指針は functional core, imperative shell だ。計算部分をすべて純粋関数にまとめ、ファイルやネットワークといったI/Oは外側の薄い層に押し出す。関数型言語で IO モナドが担う「副作用を端に寄せる」という発想を、Goでは構造の分離として実現する。

純粋なコア

package app

type Order struct {
	ID       string
	Customer domain.Email
	Unit     domain.Yen
	Qty      domain.Quantity
}

func (o Order) Total() domain.Yen { return o.Unit.Mul(o.Qty) }

// ParseOrder は純粋関数。同じ入力なら常に同じ結果を返し、I/Oをしない
func ParseOrder(line string) result.Result[Order] {
	cols := strings.Split(line, ",")
	if len(cols) != 4 {
		return result.Err[Order](fmt.Errorf("want 4 columns, got %d: %q", len(cols), line))
	}
	email, err := domain.NewEmail(cols[1])
	if err != nil {
		return result.Err[Order](err)
	}
	unit, err := strconv.ParseInt(strings.TrimSpace(cols[2]), 10, 64)
	if err != nil {
		return result.Err[Order](fmt.Errorf("unit price: %w", err))
	}
	qty, err := strconv.Atoi(strings.TrimSpace(cols[3]))
	if err != nil {
		return result.Err[Order](fmt.Errorf("quantity: %w", err))
	}
	return result.Ok(Order{
		ID:       strings.TrimSpace(cols[0]),
		Customer: email,
		Unit:     domain.Yen(unit),
		Qty:      domain.Quantity(qty),
	})
}

func Validate(o Order) result.Result[Order] {
	if !o.Qty.IsPositive() {
		return result.Err[Order](fmt.Errorf("order %s: quantity must be positive", o.ID))
	}
	if o.Unit < 0 {
		return result.Err[Order](fmt.Errorf("order %s: unit price must not be negative", o.ID))
	}
	return result.Ok(o)
}

// 失敗しうる2段階を合成する
func ParseAndValidate(line string) result.Result[Order] {
	return result.Then(ParseOrder(line), Validate)
}

集約はモノイド的な畳み込みになる。顧客ごとの合計は加算なので、入力の順番に依存しない。

func SumByCustomer(orders []Order) map[domain.Email]domain.Yen {
	return fp.Reduce(orders, map[domain.Email]domain.Yen{},
		func(acc map[domain.Email]domain.Yen, o Order) map[domain.Email]domain.Yen {
			acc[o.Customer] = acc[o.Customer].Add(o.Total())
			return acc
		})
}

// Report が純粋なコア。エラーは落とさず集めて返す
func Report(lines []string) (map[domain.Email]domain.Yen, []error) {
	parsed := fp.Map(lines, ParseAndValidate)
	var errs []error
	var orders []Order
	for _, r := range parsed {
		o, err := r.Unwrap()
		if err != nil {
			errs = append(errs, err)
			continue
		}
		orders = append(orders, o)
	}
	return SumByCustomer(orders), errs
}

SumByCustomer は畳み込みの内側でマップを書き換えているが、そのマップは関数の中で作ったものなので、外からは観測できない。関数型言語のように完全な不変性を目指すより、「外に見える副作用がない」ところまで守るほうがGoでは現実的になる。

Report は行の配列を受け取り、集計結果とエラー一覧を返すだけだ。ファイル、DB、時刻のいずれも参照しない。エラーを最初の1件で打ち切らず全部集めているのも、入力の全体像を返すためだ。

I/Oは外側の殻に置く

func main() {
	f, err := os.Open("orders.csv")
	if err != nil {
		log.Fatal(err)
	}
	defer f.Close()

	var lines []string
	sc := bufio.NewScanner(f)
	for sc.Scan() {
		lines = append(lines, sc.Text())
	}
	if err := sc.Err(); err != nil {
		log.Fatal(err)
	}

	sum, errs := app.Report(lines) // 純粋なコアを1回だけ呼ぶ
	for _, e := range errs {
		log.Printf("skip: %v", e)
	}
	for email, total := range sum {
		fmt.Printf("%s\t%s\n", email, total)
	}
}

この分離の効果はテストに直結する。コアのテストでファイルやモックは要らない。

func TestParseAndValidate(t *testing.T) {
	tests := map[string]struct {
		line    string
		wantErr bool
		want    domain.Yen
	}{
		"正常系":      {line: "o1,a@example.com,1200,2", want: 2400},
		"列が足りない":   {line: "o1,a@example.com,1200", wantErr: true},
		"メールが不正":   {line: "o1,example.com,1200,2", wantErr: true},
		"数量が0":     {line: "o1,a@example.com,1200,0", wantErr: true},
		"単価が数値でない": {line: "o1,a@example.com,abc,2", wantErr: true},
	}
	for name, tt := range tests {
		t.Run(name, func(t *testing.T) {
			o, err := ParseAndValidate(tt.line).Unwrap()
			if tt.wantErr {
				if err == nil {
					t.Fatalf("want error, got %+v", o)
				}
				return
			}
			if err != nil {
				t.Fatalf("unexpected error: %v", err)
			}
			if got := o.Total(); got != tt.want {
				t.Errorf("Total() = %v, want %v", got, tt.want)
			}
		})
	}
}

純粋関数のテストは、テーブルに入力と期待値を並べるだけで済む。テストの表がそのまま仕様の一覧になるという話は、Goで書くコード品質の高め方にも書いた。

なお、この「計算とI/Oを分ける」構造は、レイヤの依存方向を内向きに固定するオニオンアーキテクチャの考え方とも重なる。Goでの実装例はドメイン駆動設計とオニオンアーキテクチャ、Go言語での実現についてに書いた。

イテレータで遅延パイプラインにする

Go 1.23 で iter.Seq と range over func が入り、遅延的な列を扱えるようになった。全件をメモリへ載せずに流す処理や、途中で打ち切る処理と相性がよい。

func MapSeq[A, B any](seq iter.Seq[A], f func(A) B) iter.Seq[B] {
	return func(yield func(B) bool) {
		for v := range seq {
			if !yield(f(v)) {
				return
			}
		}
	}
}

func FilterSeq[A any](seq iter.Seq[A], pred func(A) bool) iter.Seq[A] {
	return func(yield func(A) bool) {
		for v := range seq {
			if pred(v) && !yield(v) {
				return
			}
		}
	}
}

yield が false を返したら即座に戻る点が重要で、これが短絡（break や slices.Collect の途中終了）を成立させている。結果を集めるには slices.Collect を使う。

1
2
3

nums := MapSeq(lines, toInt)
even := FilterSeq(nums, func(n int) bool { return n%2 == 0 })
got := slices.Collect(even) // []int{2, 4}

どこまでやるか

コストを実測する

10000要素のスライスに対し、「偶数だけ残して2倍する」処理を3通りで測った。Go 1.27.0、linux/amd64、Xeon 2.80GHz の仮想マシンでの結果を載せる。

1
2
3

BenchmarkForLoop-4         41586     28947 ns/op     81920 B/op      1 allocs/op
BenchmarkMapFilter-4       26455     47697 ns/op    122880 B/op      2 allocs/op
BenchmarkSeqPipeline-4     11673    102948 ns/op    128440 B/op     23 allocs/op

読み取れることは3つある。

Filter + Map は素朴なforループの約1.6倍の時間がかかった。中間スライスを1本余分に作るためで、割り当ても増えている
iter.Seq の遅延パイプラインは、この条件では最も遅い。全件を最後まで流す場合、yield 呼び出しのコストが効く。遅延評価が得をするのは、途中で打ち切る場合や、そもそも全件をメモリに載せられない場合だ
とはいえ絶対値は10000要素で数十マイクロ秒だ。1リクエストに数msかかるWebアプリの中では誤差の範囲になる

つまり判断は場所による。ホットパスや大きなループの内側では素直なforループを、それ以外では読みやすさを優先した合成を選ぶ。数値はマシンと入力サイズで変わるので、気になる場合は自分の環境で go test -bench . -benchmem を実行して確かめるとよい。

周辺ツールのバージョンに注意する

ジェネリックメソッドのように新しい構文を使う場合、コンパイラだけでなく周辺ツールも追随している必要がある。実際、今回の検証では次の現象が起きた。

1
2
3

$ gofmt -l .
result/result.go:66:25: method must have no type parameters
slice.go:5:22: method must have no type parameters

これはPATH上の gofmt が古いバージョン（go1.24.7 同梱）だったために起きたものだ。同じソースを go1.27.0 の gofmt にかけると何も出ない。CIやエディタが使うツールチェーンのバージョンも揃えておかないと、コンパイルは通るのにフォーマッタやリンタが落ちる、という状況になりうる。

# 実行されるツールチェーンを確認する
$ go version
$ go env GOTOOLCHAIN
$ go fmt ./...   # go 経由で呼べば go.mod のツールチェーンに従う

チームで使うときの線引き

関数型のスタイルはやりすぎると読みにくくなる。次のあたりを線引きの目安にするとよい。

積極的に使う: defined type、スマートコンストラクタ、純粋関数への分離、テーブル駆動テスト。これらはGoらしさを損なわず、効果が大きい
場合による: Map / Filter / Reduce、Monoid、Result[T]。パイプライン的な処理では読みやすくなる。単純なループ1つを置き換えるだけなら、for のままのほうがよい
避ける: 深い関数合成のネスト、独自のモナド風DSL、Result を公開APIに露出させること。読み手にGoの標準的な読み方を捨てさせる負荷が大きい

判断軸は「関数型らしいか」ではなく、「バグの分類を1つ消せるか」「読み手にとって追う概念が減るか」だ。

注意点

Goの値は自由にコピーできるが、スライスやマップを含む構造体をコピーしても中身は共有される。Map に渡した関数の中で入力のスライスやマップを書き換えると、純粋関数の前提が崩れる。不変性は規律で守るしかない
再帰は深くしないほうがよい。Goの仕様は末尾呼び出し最適化を保証しない。goroutine のスタックは伸長するのでいきなり落ちはしないが、深い再帰は素直にループで書くほうが安全になる
型switchの網羅性はコンパイラが検査しない。default の省略も言語としては許されるため、実装を増やしたときの追従は人間の責任になる。自分で default を書き、テストで固定する
ジェネリクスは万能ではない。型パラメータを増やすほど推論が効かなくなり、明示的な instantiate が必要になる場面が出てくる。読みにくくなったら、具体型で2つ書くほうが早いこともある
ここで紹介したGo 1.27 のジェネリックメソッドは、手元の go1.27.0 で挙動を確認したものだ。細かい仕様は公式のリリースノートと言語仕様を確認してほしい
本記事のコードはすべて go vet と go test を通しているが、エラー処理や境界値は説明のために簡略化してある。実運用ではCSVは encoding/csv を使うなど、標準ライブラリに任せられる部分は任せるとよい

参考

The Go Programming Language Specification — 型パラメータと defined type の一次情報
Go Wiki: Generics — ジェネリクスの公式チュートリアル
Go 1.23 Release Notes — iter パッケージと range over func
Alexis King, “Parse, don’t validate” (2019) — 型で検証結果を持ち越す考え方
Gary Bernhardt, “Boundaries” (2012) — functional core, imperative shell の出典
関数型言語と圏論 — 本記事の前提となる用語と法則の整理
Goで書くコード品質の高め方 — テストを仕様として運用する話
ドメイン駆動設計とオニオンアーキテクチャ、Go言語での実現について — 依存方向とレイヤ分割

Goで関数型プログラミングをする

型定義とジェネリクスで堅牢なアプリケーションを作る

Goで関数型プログラミングをする

まとめ

前提

関数型から何を持ち込むか

型定義で不正な状態を作れなくする

defined type で意味を型に載せる

スマートコンストラクタで「検証済み」を型にする

直和型はインターフェースと非公開メソッドで代用する

ジェネリクスで合成を書く

関数合成と恒等関数

モノイドと畳み込み

Option と Result をGoで扱う

Go 1.27 のジェネリックメソッド

それでも高階型はない

公開APIは `(T, error)` のままにする

実践: functional core, imperative shell

純粋なコア

I/Oは外側の殻に置く

イテレータで遅延パイプラインにする

どこまでやるか

コストを実測する

周辺ツールのバージョンに注意する

チームで使うときの線引き

注意点

参考

See also

Goで関数型プログラミングをする

まとめ

前提

関数型から何を持ち込むか

型定義で不正な状態を作れなくする

defined type で意味を型に載せる

スマートコンストラクタで「検証済み」を型にする

直和型はインターフェースと非公開メソッドで代用する

ジェネリクスで合成を書く

関数合成と恒等関数

モノイドと畳み込み

Option と Result をGoで扱う

Go 1.27 のジェネリックメソッド

それでも高階型はない

公開APIは (T, error) のままにする

実践: functional core, imperative shell

純粋なコア

I/Oは外側の殻に置く

イテレータで遅延パイプラインにする

どこまでやるか

コストを実測する

周辺ツールのバージョンに注意する

チームで使うときの線引き

注意点

参考

Share

See also

公開APIは `(T, error)` のままにする