List of Contract [text.Baldanders.info]

次期 Go 言語で導入される総称型について予習する（その2）

2020-06-17T07:33:04+00:00

【2021-02-21 追記】 型パラメータの提案（「総称型」というのは厳密には正しくないらしい）は2021年2月に承認され，製造フェーズに入ったようだ。

以前書いた記事に関して，仕様が変わったらしい。

そこで，これまでのおさらいと変更点について簡単に紹介する。

「総称型」のおさらい

次期 Go 言語で導入される「総称型（generics）」について，これまで提案されていた仕様は以下の通り。

contract ordered(t T) {
    t < t
}

func Max(type T ordered)(x, y T) T {
    if x < y {
        return y
    }
    return x
}

Max() 関数の (type T ordered) の部分が「型パラメータ（type parameter）」で，これによって型 T が総称型であることを示す。また ordered は「型コントラクト（type contract）」と呼ばれ，総称型に対する制約（constraint）として機能している。

制約の定義

新しい提案では，型コントラクトを捨て，制約の定義を以下のように変更する。

type ordered interface {
	type int, int8, int16, int32, int64,
		uint, uint8, uint16, uint32, uint64, uintptr,
		float32, float64,
		string
}

func Max(type T ordered)(x, y T) T {
    if x < y {
        return y
    }
    return x
}

以前の型コントラクトとの違いは 既存のキーワードがそのまま使える ことである。文法も interface 型の宣言とほぼ同じだが type int, int8, ... といった感じに型の列挙ができる点がこれまでと異なる。

これにより，制約 ordered を満たす型であれば

func main() {
	fmt.Println(Max(Max(1, 2), 3))               //Output: 3
    fmt.Printf("%#U\n", Max(Max('あ', 'い'), 0)) //Output: U+3044 'い'
}

などと記述できる。

なお，これまでの interface 型も制約として使える。たとえば，こんな感じ。

func SayError(type E error)(e E) string {
	return e.Error()
}

func main() {
	fmt.Println(SayError(io.EOF)) //Output: EOF
}

更に interface 型を入れ子にすることで複雑な制約条件を構成することもできる。

注入するか単態化するか

ところで先程の

func SayError(type E error)(e E) string {
	return e.Error()
}

は，わざわざ総称型を使わなくとも今までの書き方で

func SayError(e error) string {
	return e.Error()
}

としても見た目の結果は同じになる。

しかし，今までの書き方が実行時に動的ディスパッチを行う「依存の注入（depencency injection）」であるのに対し，総称型を使った記述はコンパイル時に型ごとに別々の関数として展開される。これを「単態化（monomorphization）」と呼ぶ。

依存の注入と単態化ではリソース管理の戦略がまるで異なる。

たとえば上述の SayError() 関数を総称型で記述するのは，どう考えても効率が悪い。 error に包摂される型は必要に応じていくらでも定義可能であり，それらの型ごとに単態化されるなどぞんぞがさばる。

逆に Max() 関数なんかは，基本型の振る舞いを interface で括るのが難しいこともあり，コストの高い float64 型の math.Max() くらいしか標準では実装されてなかったりする。こういったものを総称型で記述できるようになれば（OAOO 原則の観点から考えても）コード管理しやすくなるだろう。

「Go プログラマは息をするように依存を注入する」。他のプログラミング言語が総称型で書いているかなりの部分を依存の注入で簡単に纏めてしまえるのが Go 言語の強みであるが，使える道具は多いに越したことはない。

Go 2 Playground

次期 Go 言語用に新しい Playground が公開されている。

https://go2goplay.golang.org/

総称型についてもここで色々と試せるようなので，遊びに行ってみてはいかがだろうか。

早ければ Go 1.17 でお披露目？

だいぶ仕様が固まってきた総称型であるが，早ければ2021年8月にリリース予定の Go 1.17 でお披露目されるかもしれないとのこと。

たのしみ！

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

著者のひとりは（あの「バイブル」とも呼ばれる）通称 “K&R” の K のほうである。この本は Go 言語の教科書と言ってもいいだろう。と思ったら絶版状態らしい（2025-01 現在）。復刊を望む！

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

次期 Go 言語で導入される（かもしれない）総称型について予習する

2018-11-10T21:10:48+00:00

2018年8月に次期 Go 言語で追加される（かもしれない）仕様についてアナウンスがあった。

Go 2 Drafts Announcement - YouTubeより

“Go 2” といってもメジャー・バージョンが変わるのではなく現行バージョンに対する追加仕様らしい。したがって後方互換性は確保されているようだ。

紹介されているドラフト案は大きく2つある。

総称型（generics）
- Generics — Problem Overview
- Contracts — Draft Design
エラー・ハンドリングに関するもの

このうち今回は総称型について予習してみる。

なお “Go 2” の提案はまだドラフト段階なので大幅に変更になったり場合によっては立ち消えになる可能性もある。なので，この記事では深いところまで踏み込まずフワっとした説明になるけど，あしからずご了承の程を。

総称型のメリット

ソフトウェア・エンジニアには自明だと思うが，まずは復習から。

具体例として2つの値のうち大きい方を返す関数を考えてみる。

package main

import "fmt"

func max(x, y int) int {
    if x < y {
        return y
    }
    return x
}

func main() {
    x := 1
    y := 2
    fmt.Printf("max(%v, %v) = %v\n", x, y, max(x, y))
    //Output
    //max(1, 2) = 2
}

この関数 max() は int 型で記述しているが byte 型や float32/float64 型でも関数の中身は全く同じコードになる。

package main

import "fmt"

func max(x, y float64) float64 {
    if x < y {
        return y
    }
    return x
}

func main() {
    x := 1.1
    y := 1.2
    fmt.Printf("max(%v, %v) = %v\n", x, y, max(x, y))
    //Output
    //max(1.1, 1.2) = 1.2
}

ならば，最初から汎化した型で単一のコード記述すれば型ごとに複数のコードを量産しなくてもいんじゃね？という発想になる¹。これが総称型の原点である。

たとえば Java で総称型を使うと以下のような記述になる²。

public static <T> T max(T x, T y) {
    ...
}

<T> の部分が総称型の定義にあたる。ちなみに総称型の名前（この場合は T）はスコープ内で被らなければ任意に指定できる。

現行版 Go 言語において総称型の不在で割りを食っている典型例のひとつが sort パッケージで，基本型の slice のソートだけで以下の型が用意されている³。

sort.Float64Slice
sort.IntSlice
sort.StringSlice

後方互換性を確保するため，これらの型がなくなることはないだろうけど，総称型が実現すれば内部実装の refactoring が進むかも知れない。

このように総称型はコンテナ（container; オブジェクトの集合を表現するデータ構造）操作で特に威力を発揮する。また，現行版 Go 言語では総称型を用いずとも interface 型と reflect パッケージを使ってかなりの部分を代替できるが，コード量のコスト高を別にしても，記述の正しさは実行時での評価ではなくコンパイル時に評価して欲しいところである。

そういうわけで，今までずうっと後回しにされてきたが，総称型を導入できるのであれば是非とも期待したいものである。

型パラメータ（Type Parameter）と型引数（Type Argument）

次期 Go 言語で総称型を導入するために型パラメータおよび型引数の構文を追加するようだ。

例えば先程の max() 関数であれば以下のように記述できる。

package main

import "fmt"

func max(type T)(x, y T) T {
    if x < y {
        return y
    }
    return x
}

func main() {
    x := 1
    y := 2
    fmt.Printf("max(%v, %v) = %v\n", x, y, max(x, y))
    //Output
    //max(1, 2) = 2
}

(type T) の部分が型パラメータで，これによって総称型を定義している。既存の語彙だけで構成しているのがポイント（< や > は演算子だし [...] は配列/slice や map の構文で使われるので避けたのだろう）。

関数を呼び出す側は型推論によって引数の型が一意に決定するので特別な記述は必要ない。相変わらず refatoring に優しい言語だよな（笑）

明示的に型を指定するなら

max(int)(x, y)

などと記述する。 (int) の部分が型引数にあたる。

型宣言とインスタンス生成でも同様に

type List(type T) []T

var listInt = List(int){0, 1, 2, 3, 4 ,5}

などと記述できる。

型コントラクト（Type Contract）

先程の max() 関数だが

func max(type T)(x, y T) T {
    if x < y {
        return y
    }
    return x
}

型 T のインスタンス同士で比較演算（具体的には x < y）が可能である必要がある。たとえば complex64/complex128 は基本型だが < 演算子による比較ができない。

Java の場合は継承を構成して

public static <T extends Comparable<? super T>> T max(T x, T y) {
    ...
}

などと記述することで総称型に対する制約（type constraint）を表現できる⁴。

しかし Go 言語ではいわゆる「継承」の仕組みを持ってないため別のアプローチをとる必要がある。それが型コントラクトである。型コントラクトでは contract キーワードおよびそれを使った構文を追加する。具体的には以下のようなコードになる。

contract comparable(t T) {
    t < t
}

func max(type T comparable)(x, y T) T {
    if x < y {
        return y
    }
    return x
}

なお comparable の型引数を明示する場合は

func max(type T comparable(T))(x, y T) T { ... }

と書く。

型コントラクトの記述はバイナリ・コードにコンパイルされない。上の例では型 T に対して比較演算子 < が使えることを要求しているとコンパイラに知らせるものである。これなら T を complex128 に展開しようとしてもコンパイル時に「契約違反」になるわけだ。

型コントラクトは型コントラクトに埋め込むことができる。例えばこんな感じ。

contract equalable(t T) {
    t == t
}
contract comparable(t T) {
    equalable(T)
    t < t
}

これで comparable は == 演算子と < 演算子が使えることを要求していることになる。

継承を利用した制約と異なり，型コントラクトの自由度は高く応用範囲も広い。たとえばポインタ型を要求するなら

contract pointer(t T) {
    *t
}

などと書くこともできるらしい。他にも io.Reader と汎化・特化の関係があることを要求するなら

contract readable(r T) {
    io.Reader(r)
}

などと書けばいいようだ。

もし今回のドラフト案の通りに総称型が実現するなら型コントラクトの整備が喫緊の作業となるだろう。

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

このように同じコードを重複させないように記述するコーディング指針を「OAOO (Once And Only Once) 原則」と呼ぶ。そういえばよくある勘違いで「DRY (Don’t Repeat Yourself) 原則」と解説している記事が見受けられるが， DRY 原則は同じ意味を持つ情報やデータを複数に散らばせないというシステム設計や開発環境の指針を指すものである。 ↩︎
久しぶりに Java コード書いたら型を前置することに違和感がハンパない。型の前置なんて非合理的だよなあ（もちろん偏見w） ↩︎
Slice のソートについてはバージョン 1.8 から任意の型に対応する sort.Slice() 関数が用意された。内部で reflect パッケージを使っているが，かなり巧妙に組まれているため，パフォーマンス低下は殆どないらしい。ただし slice 以外のインスタンスを指定すると（コンパイル時ではなく）実行時に panic を吐く。詳しくは「ソートを使う」を参照のこと。 ↩︎
C++ や C# でも where 句を用いて総称型に対する制約を表現できるが，基本は継承を利用したものである。 ↩︎