Go 1 リリースノート

Go 1 の概要

Goバージョン1、略してGo 1は、信頼性の高い製品、プロジェクト、出版物を制作するための安定した基盤を提供する言語とコアライブラリのセットを定義します。

Go 1の主な動機は、ユーザーの安定性です。人々はGoプログラムを作成し、Google App Engineなどの実稼働環境を含め、何年にもわたって変更なしにコンパイルおよび実行され続けることを期待できるべきです。同様に、人々はGoに関する本を執筆し、その本が記述しているGoのバージョンを述べることができ、そのバージョン番号が後になってからも意味を持つべきです。

Go 1でコンパイルされたコードは、いくつかの例外を除き、Goバージョン1.1、1.2などの更新やバグ修正を発行しても、そのバージョンのライフタイムを通じてコンパイルと実行を継続する必要があります。重大な修正を除き、Go 1の後続リリースに向けて言語およびライブラリに加えられた変更は、機能を追加する可能性はありますが、既存のGo 1プログラムを壊すことはありません。Go 1の互換性ドキュメントでは、互換性のガイドラインについて詳しく説明しています。

Go 1は、言語の大幅な再考ではなく、今日使用されているGoの表現です。新しい機能を設計することは避け、代わりに問題や矛盾の解消、移植性の向上に焦点を当てました。以前から検討しプロトタイプを作成したが、主に重要であり後方互換性がないためリリースしていなかったGo言語とパッケージへの多くの変更があります。Go 1はそれらを公開する機会であり、長期的には役立ちますが、古いプログラムとの非互換性がGo 1で導入されることも意味します。幸いなことに、go fixツールは、プログラムをGo 1標準に準拠させるために必要な作業の多くを自動化できます。

このドキュメントでは、既存のコードを更新するプログラマーに影響を与えるGo 1の主な変更点を概説します。その基準点は、以前のリリースであるr60(r60.3としてタグ付け)です。また、r60からGo 1で実行するようにコードを更新する方法についても説明します。

言語への変更

Append

appendの事前宣言された可変長引数関数を使用すると、末尾に要素を追加してスライスを簡単に拡張できます。一般的な使用例は、出力を生成するときにバイトスライスの末尾にバイトを追加することです。ただし、appendは、別の一般的なケースである文字列を[]byteに追加する方法を提供しませんでした。

    greeting := []byte{}
    greeting = append(greeting, []byte("hello ")...)

copyの同様のプロパティとの類似性から、Go 1では文字列をバイトスライスに直接(バイト単位で)追加することができ、文字列とバイトスライス間の摩擦を軽減できます。変換は不要になりました。

    greeting = append(greeting, "world"...)

更新: これは新機能であるため、既存のコードを変更する必要はありません。

Close

closeの事前宣言された関数は、送信者が値がこれ以上送信されないことを通知するメカニズムを提供します。チャネルに対するfor rangeループの実装にとって重要であり、他の状況でも役立ちます。部分的には設計により、部分的にはそうでない場合に発生する可能性のある競合状態により、データの受信側ではなく、チャネルで送信するゴルーチンのみが使用することを意図しています。ただし、Go 1より前は、closeが正しく使用されていることをコンパイル時にチェックする機能はありませんでした。

少なくとも部分的にこのギャップを埋めるために、Go 1では、受信専用チャネルでのcloseを許可していません。このようなチャネルを閉じようとすると、コンパイル時エラーが発生します。

    var c chan int
    var csend chan<- int = c
    var crecv <-chan int = c
    close(c)     // legal
    close(csend) // legal
    close(crecv) // illegal

更新: 受信専用チャネルを閉じようとする既存のコードは、Go 1の前でも誤りであり、修正する必要があります。コンパイラは、このようなコードを拒否するようになりました。

複合リテラル

Go 1では、配列、スライス、またはマップ型の複合リテラルは、要素のイニシャライザがポインター型の場合、型指定を省略できます。この例の4つの初期化はすべて正当です。最後の1つはGo 1より前では不正でした。

    type Date struct {
        month string
        day   int
    }
    // Struct values, fully qualified; always legal.
    holiday1 := []Date{
        Date{"Feb", 14},
        Date{"Nov", 11},
        Date{"Dec", 25},
    }
    // Struct values, type name elided; always legal.
    holiday2 := []Date{
        {"Feb", 14},
        {"Nov", 11},
        {"Dec", 25},
    }
    // Pointers, fully qualified, always legal.
    holiday3 := []*Date{
        &Date{"Feb", 14},
        &Date{"Nov", 11},
        &Date{"Dec", 25},
    }
    // Pointers, type name elided; legal in Go 1.
    holiday4 := []*Date{
        {"Feb", 14},
        {"Nov", 11},
        {"Dec", 25},
    }

更新: この変更は既存のコードには影響しませんが、既存のソースに適用されたコマンドgofmt -sは、許可されている場所であれば、明示的な要素型を省略します。

初期化中のゴルーチン

古い言語では、初期化中に実行されたgoステートメントはゴルーチンを作成するが、プログラム全体の初期化が完了するまで実行を開始しないと定義されていました。これにより、多くの場所で扱いにくさが発生し、事実上、initコンストラクトの有用性が制限されました。別のパッケージが初期化中にライブラリを使用できる場合、ライブラリはゴルーチンを避けることを余儀なくされました。この設計は、単純さと安全性の理由から行われましたが、言語への信頼が高まるにつれて、不要に見えました。初期化中にゴルーチンを実行することは、通常の実行中に実行するよりも複雑でも危険でもありません。

Go 1では、ゴルーチンを使用するコードは、デッドロックを発生させることなく、initルーチンおよびグローバル初期化式から呼び出すことができます。

var PackageGlobal int

func init() {
    c := make(chan int)
    go initializationFunction(c)
    PackageGlobal = <-c
}

更新: これは新機能であるため、既存のコードを変更する必要はありませんが、mainの前にゴルーチンが開始されないことに依存するコードが破損する可能性があります。標準リポジトリにはそのようなコードはありませんでした。

rune型

言語仕様では、int型は32ビットまたは64ビット幅にすることができますが、現在の実装では、64ビットプラットフォームでもintを32ビットに設定しています。intが64ビットプラットフォームで64ビットになるのが望ましいでしょう(大きなスライスをインデックス化する上で重要な結果があります)。ただし、古い言語ではUnicodeコードポイントを保持するためにもint型が使用されていたため、この変更によりUnicode文字を処理するときに領域が浪費されます。intが32ビットから64ビットに拡張された場合、各コードポイントは余分な32ビットのストレージを浪費します。

64ビットintへの変更を可能にするために、Go 1では、個々のUnicodeコードポイントを表す新しい基本型runeが導入されました。これは、uint8のエイリアスとしてのbyteと同様に、int32のエイリアスです。

'a''語''\u0345'などの文字リテラルには、デフォルトの型runeが与えられるようになりました。これは、1.0にデフォルトの型float64が与えられるのと同様です。したがって、文字定数に初期化された変数は、特に指定がない限り、型runeになります。

ライブラリは、適切な場合はintではなくruneを使用するように更新されました。たとえば、関数unicode.ToLowerおよび関連関数は、runeを受け取り、runeを返すようになりました。

    delta := 'δ' // delta has type rune.
    var DELTA rune
    DELTA = unicode.ToUpper(delta)
    epsilon := unicode.ToLower(DELTA + 1)
    if epsilon != 'δ'+1 {
        log.Fatal("inconsistent casing for Greek")
    }

更新: :=イニシャライザからの型推論が新しい型を暗黙的に導入し、そこから伝播するため、ほとんどのソースコードはこの影響を受けません。一部のコードでは、簡単な変換で解決する型エラーが発生する場合があります。

error型

Go 1では、次の定義を持つ新しい組み込み型errorが導入されています

    type error interface {
        Error() string
    }

この型の結果はすべてパッケージライブラリにあるため、以下で説明します。

マップからの削除

古い言語では、マップmからキーkのエントリを削除するために、次のステートメントを記述しました。

    m[k] = value, false

この構文は、唯一の2対1の代入である、特異な特殊なケースでした。評価はされるものの破棄される値(通常は無視される)と、ほぼ常に定数falseであるブール値を渡す必要がありました。機能はしましたが、奇妙で議論の的でした。

Go 1では、その構文はなくなりました。代わりに、新しい組み込み関数deleteがあります。呼び出し

    delete(m, k)

は、式m[k]で取得されたマップエントリを削除します。戻り値はありません。存在しないエントリを削除しても、何も行われません。

更新: go fixを実行すると、無視された値をプログラムから安全に破棄でき、falseが事前定義されたブール定数を参照していることが明らかな場合に、m[k] = value, falseの形式の式がdelete(m, k)に変換されます。fixツールは、プログラマーによる検査のために、構文の他の使用箇所にフラグを立てます。

マップでの反復処理

古い言語仕様では、マップの反復処理の順序が定義されておらず、実際にはハードウェアプラットフォームによって異なっていました。これにより、マップを反復処理するテストは脆弱で移植性がなくなり、あるマシンでは常にテストが合格する可能性があるが、別のマシンでは破損する可能性があるという不快なプロパティがありました。

Go 1では、for rangeステートメントを使用してマップを反復処理するときに要素が訪問される順序は、同じループを同じマップで複数回実行した場合でも、予測不可能であると定義されています。コードは、要素が特定の順序で訪問されると想定するべきではありません。

この変更は、反復処理の順序に依存するコードが早期に破損する可能性が高く、問題になる前に修正されることを意味します。同様に重要なこととして、プログラムが範囲ループを使用してマップから要素を選択している場合でも、マップの実装でより適切なマップのバランスを確保できるようになります。

    m := map[string]int{"Sunday": 0, "Monday": 1}
    for name, value := range m {
        // This loop should not assume Sunday will be visited first.
        f(name, value)
    }

更新: これは、ツールが役立たない変更の1つです。既存のほとんどのコードは影響を受けませんが、一部のプログラムが破損したり、誤動作したりする可能性があります。マップに対するすべての範囲ステートメントを手動でチェックし、反復処理の順序に依存していないことを確認することをお勧めします。標準リポジトリにはいくつかのそのような例がありました。それらは修正されました。反復処理の順序に依存することは、すでに指定されておらず、間違っていたことに注意してください。この変更は、予測不可能さを明文化したものです。

複数代入

言語仕様では、代入では、左辺の式が代入される前に、右辺の式がすべて評価されることが長い間保証されています。予測可能な動作を保証するために、Go 1は仕様をさらに改善しています。

代入ステートメントの左辺に、関数呼び出しや配列インデックス操作など、評価が必要な式が含まれている場合、これらの式はすべて、変数が値に代入される前に、通常の左から右へのルールを使用して行われます。すべてが評価されると、実際の代入が左から右への順序で進行します。

これらの例は、動作を示しています。

    sa := []int{1, 2, 3}
    i := 0
    i, sa[i] = 1, 2 // sets i = 1, sa[0] = 2

    sb := []int{1, 2, 3}
    j := 0
    sb[j], j = 2, 1 // sets sb[0] = 2, j = 1

    sc := []int{1, 2, 3}
    sc[0], sc[0] = 1, 2 // sets sc[0] = 1, then sc[0] = 2 (so sc[0] = 2 at end)

更新: これは、ツールが役立たない変更の1つですが、破損が発生する可能性は低いです。標準リポジトリ内のどのコードもこの変更によって破損しておらず、以前に指定されていなかった動作に依存するコードはすでに間違っていました。

戻り値とシャドウイングされた変数

よくある間違いは、結果変数と同じ名前を持つが同じ変数ではない変数への代入の後で、return(引数なし)を使用することです。この状況はシャドウイングと呼ばれます。結果変数は、内側のスコープで宣言された同じ名前の別の変数によってシャドウイングされています。

名前付き戻り値を持つ関数では、名前付き戻り値のいずれかがreturnステートメントの時点でシャドウイングされている場合、Go 1コンパイラは引数なしのreturnステートメントを許可しません(これは、まだ調査中の領域の1つであるため、仕様の一部ではありません。状況は、明示的なreturnステートメントで終わらない関数をコンパイラが拒否するのと類似しています)。

この関数は暗黙的にシャドウイングされた戻り値を返し、コンパイラによって拒否されます

func Bug() (i, j, k int) {
    for i = 0; i < 5; i++ {
        for j := 0; j < 5; j++ { // Redeclares j.
            k += i * j
            if k > 100 {
                return // Rejected: j is shadowed here.
            }
        }
    }
    return // OK: j is not shadowed here.
}

更新: このように戻り値を隠蔽するコードはコンパイラによって拒否され、手動で修正する必要があります。標準リポジトリで発生したケースはほとんどがバグでした。

非公開フィールドを持つ構造体のコピー

古い言語では、パッケージが別のパッケージに属する非公開フィールドを含む構造体値をコピーすることを許可していませんでした。ただし、メソッドレシーバーには必須の例外がありました。また、copy および append の実装は、この制限を尊重していませんでした。

Go 1 では、パッケージが他のパッケージから非公開フィールドを含む構造体値をコピーできるようになります。この不整合を解消することに加えて、この変更により新しい種類の API が可能になります。パッケージは、ポインターやインターフェースに頼らずに不透明な値を返すことができます。time.Time および reflect.Value の新しい実装は、この新しいプロパティを利用した型の例です。

例として、パッケージ p に次の定義が含まれている場合、

    type Struct struct {
        Public int
        secret int
    }
    func NewStruct(a int) Struct {  // Note: not a pointer.
        return Struct{a, f(a)}
    }
    func (s Struct) String() string {
        return fmt.Sprintf("{%d (secret %d)}", s.Public, s.secret)
    }

p をインポートするパッケージは、型 p.Struct の値を自由に代入およびコピーできます。舞台裏では、非公開フィールドはエクスポートされた場合と同じように代入およびコピーされますが、クライアントコードはそれらに気づきません。次のコード

    import "p"

    myStruct := p.NewStruct(23)
    copyOfMyStruct := myStruct
    fmt.Println(myStruct, copyOfMyStruct)

は、構造体の秘密フィールドが新しい値にコピーされたことを示します。

更新: これは新機能であるため、既存のコードを変更する必要はありません。

等価性

Go 1 より前は、言語は構造体と配列の値に対する等価性を定義していませんでした。これは、とりわけ、構造体と配列をマップキーとして使用できなかったことを意味します。一方、Go は関数とマップの値に対する等価性を定義していました。関数の等価性はクロージャの存在下で問題がありました(2 つのクロージャが等しいのはいつか?)。一方、マップの等価性は、マップの内容ではなくポインターを比較しましたが、これは通常、ユーザーが望むものではありませんでした。

Go 1 では、これらの問題に対処しました。まず、構造体と配列は等価性および不等価性 (== および !=) を比較でき、したがって、要素ごとの比較を使用して、等価性が定義されている要素で構成されている場合に、マップキーとして使用できます。

    type Day struct {
        long  string
        short string
    }
    Christmas := Day{"Christmas", "XMas"}
    Thanksgiving := Day{"Thanksgiving", "Turkey"}
    holiday := map[Day]bool{
        Christmas:    true,
        Thanksgiving: true,
    }
    fmt.Printf("Christmas is a holiday: %t\n", holiday[Christmas])

次に、Go 1 では、nil との比較を除き、関数値の等価性の定義を削除します。最後に、マップの等価性も、nil との比較を除いてなくなりました。

一般的に計算が不可能なスライスでは、等価性が定義されていないことに注意してください。また、順序比較演算子 (< <= > >=) は、構造体と配列では依然として定義されていないことに注意してください。

更新: 構造体と配列の等価性は新しい機能であるため、既存のコードを変更する必要はありません。関数またはマップの等価性に依存する既存のコードは、コンパイラによって拒否され、手動で修正する必要があります。影響を受けるプログラムはわずかですが、修正には設計の再考が必要になる場合があります。

パッケージ階層

Go 1 は、古い標準ライブラリの多くの欠陥に対処し、多くのパッケージを整理し、それらをより内部的に一貫性があり、移植可能にしました。

このセクションでは、Go 1 でパッケージがどのように再編成されたかを説明します。移動したもの、名前が変更されたもの、削除されたものがあります。新しいパッケージについては、後のセクションで説明します。

パッケージ階層

Go 1 には、関連するアイテムをサブディレクトリにグループ化した再編成されたパッケージ階層があります。たとえば、utf8 および utf16 は、unicode のサブディレクトリに存在します。また、一部のパッケージcode.google.com/p/go のサブリポジトリに移動し、他のパッケージ は完全に削除されました。

古いパス 新しいパス

asn1 encoding/asn1
csv encoding/csv
gob encoding/gob
json encoding/json
xml encoding/xml

exp/template/html html/template

big math/big
cmath math/cmplx
rand math/rand

http net/http
http/cgi net/http/cgi
http/fcgi net/http/fcgi
http/httptest net/http/httptest
http/pprof net/http/pprof
mail net/mail
rpc net/rpc
rpc/jsonrpc net/rpc/jsonrpc
smtp net/smtp
url net/url

exec os/exec

scanner text/scanner
tabwriter text/tabwriter
template text/template
template/parse text/template/parse

utf8 unicode/utf8
utf16 unicode/utf16

古い cmath および exp/template/html パッケージのパッケージ名が cmplx および template に変更されたことに注意してください。

更新: go fix を実行すると、標準リポジトリ内に残っているパッケージのすべてのインポートとパッケージの名前変更が更新されます。標準リポジトリに存在しなくなったパッケージをインポートするプログラムは、手動で編集する必要があります。

パッケージツリー exp

標準化されていないため、exp ディレクトリにあるパッケージは、標準の Go 1 リリースディストリビューションでは利用できませんが、リポジトリ のソースコード形式で、それらを使用したい開発者向けに利用可能になります。

Go 1 のリリース時に、いくつかのパッケージが exp に移動しました

(EscapeString および UnescapeString 型は、パッケージ html に残ります。)

これらのパッケージはすべて、接頭辞 exp/ を付けて、同じ名前で利用できます。exp/ebnf など。

また、utf8.String 型は独自のパッケージ exp/utf8string に移動しました。

最後に、gotype コマンドは exp/gotype に存在し、ebnflintexp/ebnflint に存在します。インストールされている場合、これらは $GOROOT/bin/tool に存在します。

更新: exp のパッケージを使用するコードは、手動で更新するか、exp が利用可能なインストールからコンパイルする必要があります。go fix ツールまたはコンパイラは、そのような使用について警告します。

パッケージツリー old

非推奨のため、old ディレクトリにあるパッケージは、標準の Go 1 リリースディストリビューションでは利用できませんが、それらを使用したい開発者向けにソースコード形式で利用可能になります。

新しい場所にあるパッケージは次のとおりです

更新: 現在 old にあるパッケージを使用するコードは、手動で更新するか、old が利用可能なインストールからコンパイルする必要があります。go fix ツールは、そのような使用について警告します。

削除されたパッケージ

Go 1 では、いくつかのパッケージが完全に削除されました

およびコマンド gotry も削除されました。

更新: container/vector を使用するコードは、スライスを直接使用するように更新する必要があります。いくつかの提案については、Go 言語コミュニティ Wiki を参照してください。他のパッケージを使用するコード (ほぼゼロであるはず) は、再検討する必要があります。

サブリポジトリに移動するパッケージ

Go 1 では、多くのパッケージが他のリポジトリ、通常は メインの Go リポジトリ のサブリポジトリに移動しました。この表は、古いインポートパスと新しいインポートパスをリストしています

古い 新しい

crypto/bcrypt code.google.com/p/go.crypto/bcrypt
crypto/blowfish code.google.com/p/go.crypto/blowfish
crypto/cast5 code.google.com/p/go.crypto/cast5
crypto/md4 code.google.com/p/go.crypto/md4
crypto/ocsp code.google.com/p/go.crypto/ocsp
crypto/openpgp code.google.com/p/go.crypto/openpgp
crypto/openpgp/armor code.google.com/p/go.crypto/openpgp/armor
crypto/openpgp/elgamal code.google.com/p/go.crypto/openpgp/elgamal
crypto/openpgp/errors code.google.com/p/go.crypto/openpgp/errors
crypto/openpgp/packet code.google.com/p/go.crypto/openpgp/packet
crypto/openpgp/s2k code.google.com/p/go.crypto/openpgp/s2k
crypto/ripemd160 code.google.com/p/go.crypto/ripemd160
crypto/twofish code.google.com/p/go.crypto/twofish
crypto/xtea code.google.com/p/go.crypto/xtea
exp/ssh code.google.com/p/go.crypto/ssh

image/bmp code.google.com/p/go.image/bmp
image/tiff code.google.com/p/go.image/tiff

net/dict code.google.com/p/go.net/dict
net/websocket code.google.com/p/go.net/websocket
exp/spdy code.google.com/p/go.net/spdy

encoding/git85 code.google.com/p/go.codereview/git85
patch code.google.com/p/go.codereview/patch

exp/wingui code.google.com/p/gowingui

更新: go fix を実行すると、これらのパッケージのインポートが新しいインポートパスを使用するように更新されます。これらのパッケージに依存するインストールでは、go get コマンドを使用してインストールする必要があります。

ライブラリの主な変更点

このセクションでは、コアライブラリへの重要な変更点、つまり最も多くのプログラムに影響を与える変更点について説明します。

エラー型と errors パッケージ

パッケージ osos.Error が配置されているのは、ほとんど歴史的なものです。エラーは最初にパッケージ os を実装するときに発生し、当時はシステム関連であるように見えました。それ以来、エラーはオペレーティングシステムよりも基本的なものであることが明らかになりました。たとえば、syscall のように、os が依存するパッケージで Errors を使用できると便利です。また、osError があると、そうでなければ存在しない os への依存関係が多くなります。

Go 1 では、組み込みの error インターフェース型と、ユーティリティ関数を含む個別の errors パッケージ (bytes および strings と同様) を導入することで、これらの問題を解決します。os.NewErrorerrors.New に置き換え、エラーを環境でより中心的な位置に配置します。

したがって、広く使用されている String メソッドは、error インターフェースの偶発的な満足度を引き起こさないため、error インターフェースは、そのメソッドに代わりに名前 Error を使用します

    type error interface {
        Error() string
    }

fmt ライブラリは、エラー値を簡単に印刷するために、すでに String に対して行っているように、Error を自動的に呼び出します。

type SyntaxError struct {
    File    string
    Line    int
    Message string
}

func (se *SyntaxError) Error() string {
    return fmt.Sprintf("%s:%d: %s", se.File, se.Line, se.Message)
}

すべての標準パッケージは、新しいインターフェースを使用するように更新されました。古い os.Error はなくなりました。

新しいパッケージ errors には、次の関数が含まれています

func New(text string) error

文字列をエラーに変換します。これは、古い os.NewError を置き換えます。

    var ErrSyntax = errors.New("syntax error")

更新: go fix を実行すると、変更の影響を受けるほぼすべてのコードが更新されます。String メソッドを持つエラー型を定義するコードは、メソッドの名前を Error に変更するために、手動で更新する必要があります。

システムコールエラー

os.Error (およびその他ほぼすべてのもの) より前に存在していた古い syscall パッケージは、エラーを int 値として返していました。次に、os パッケージは、EINVAL などのこれらのエラーの多くを転送しましたが、各プラットフォームで異なるエラーセットを使用しました。この動作は、不快で移植性がないものでした。

Go 1では、syscall パッケージは、システムコールのエラーに対して error を返すようになりました。Unix では、実装は error を満たす syscall.Errno 型によって行われ、以前の os.Errno を置き換えます。

os.EINVAL およびその関連事項に影響を与える変更については、別の箇所で説明しています。

更新: go fix を実行すると、この変更の影響を受けるほぼすべてのコードが更新されます。いずれにしても、ほとんどのコードは syscall ではなく os パッケージを使用する必要があるため、影響を受けません。

時間

プログラミング言語で時間を適切にサポートすることは常に課題です。以前の Go の time パッケージには int64 単位があり、真の型安全性がなく、絶対時間と期間を区別できませんでした。

したがって、Go 1 ライブラリで最も大規模な変更の 1 つは、time パッケージの完全な再設計です。int64 としてのナノ秒の整数ではなく、時間や年などの人間的な単位を扱うための個別の *time.Time 型の代わりに、2 つの基本的な型があります。それは、ある時点を表す time.Time (値であるため、* はなくなりました) と、間隔を表す time.Duration です。どちらもナノ秒単位の分解能を持っています。Time は遠い過去から遠い未来までの任意の時間を表すことができますが、Duration はプラスマイナス約 290 年間しか表すことができません。これらの型にはメソッドがあり、time.Second のような役立つ事前定義された定数期間が多数あります。

新しいメソッドには、TimeDuration を加算する Time.Add や、2 つの Time を減算して Duration を生成する Time.Sub などがあります。

最も重要な意味的な変更は、Unix エポック (1970 年 1 月 1 日) が Unix について言及する関数とメソッドでのみ関連するようになったことです。たとえば、time.Unix や、Time 型の Unix および UnixNano メソッドです。特に、time.Now は、古い API では Unix エポックからのナノ秒の整数カウントではなく、time.Time 値を返します。

// sleepUntil sleeps until the specified time. It returns immediately if it's too late.
func sleepUntil(wakeup time.Time) {
    now := time.Now() // A Time.
    if !wakeup.After(now) {
        return
    }
    delta := wakeup.Sub(now) // A Duration.
    fmt.Printf("Sleeping for %.3fs\n", delta.Seconds())
    time.Sleep(delta)
}

新しい型、メソッド、および定数は、ファイルタイムスタンプの表現など、時間を使用するすべての標準パッケージに伝播されました。

更新: go fix ツールは、古い time パッケージの使用箇所を、新しい型とメソッドを使用するように多く更新します。ただし、1 秒あたりのナノ秒数を表す 1e9 のような値は置き換えません。また、発生する値の一部の型が変更されたため、fix ツールによって書き換えられた一部の式は、さらに手動で編集が必要になる場合があります。そのような場合、書き換えには古い機能のための正しい関数またはメソッドが含まれますが、型が間違っているか、さらに分析が必要になる可能性があります。

ライブラリへの小さな変更

このセクションでは、あまり使用されていないパッケージへの変更や、go fix を実行する必要がある以外にはほとんどのプログラムに影響を与えない変更など、小さな変更について説明します。このカテゴリには、Go 1 で新しいパッケージが含まれます。全体として、これらは移植性を向上させ、動作を正規化し、インターフェイスをよりモダンで Go のようにします。

archive/zip パッケージ

Go 1 では、*zip.WriterWrite メソッドがなくなりました。その存在は間違いでした。

更新: 影響を受けるごくわずかなコードはコンパイラによってキャッチされ、手動で更新する必要があります。

bufio パッケージ

Go 1 では、bufio.NewReaderSize および bufio.NewWriterSize 関数は、無効なサイズに対してエラーを返さなくなりました。引数のサイズが小さすぎるか無効な場合は、調整されます。

更新: go fix を実行すると、エラーを _ に代入する呼び出しが更新されます。修正されない呼び出しはコンパイラによってキャッチされ、手動で更新する必要があります。

compress/flate、compress/gzip、および compress/zlib パッケージ

Go 1 では、compress/flatecompress/gzip および compress/zlibNewWriterXxx 関数はすべて、圧縮レベルを取得する場合は (*Writer, error) を返し、それ以外の場合は *Writer を返します。パッケージ gzipCompressor および Decompressor 型は、Writer および Reader に名前が変更されました。パッケージ flateWrongValueError 型は削除されました。

更新: go fix を実行すると、古い名前とエラーを _ に代入する呼び出しが更新されます。修正されない呼び出しはコンパイラによってキャッチされ、手動で更新する必要があります。

crypto/aes および crypto/des パッケージ

Go 1 では、Reset メソッドが削除されました。Go はメモリがコピーされないことを保証しないため、このメソッドは誤解を招きました。

暗号固有の型である *aes.Cipher*des.Cipher、および *des.TripleDESCipher は、cipher.Block に置き換えられました。

更新: Reset の呼び出しを削除します。特定の暗号型の使用箇所を cipher.Block に置き換えます。

crypto/elliptic パッケージ

Go 1 では、elliptic.Curve は、代替実装を許可するためのインターフェイスになりました。カーブパラメータは elliptic.CurveParams 構造体に移動されました。

更新: *elliptic.Curve の既存のユーザーは、単に elliptic.Curve に変更する必要があります。MarshalUnmarshal、および GenerateKey の呼び出しは、elliptic.Curve を最初の引数として取る crypto/elliptic の関数になりました。

crypto/hmac パッケージ

Go 1 では、hmac.NewMD5 のようなハッシュ固有の関数は、crypto/hmac から削除されました。代わりに、hmac.Newmd5.New のような hash.Hash を返す関数を受け取ります。

更新: go fix を実行すると、必要な変更が実行されます。

crypto/x509 パッケージ

Go 1 では、crypto/x509CreateCertificate 関数と CreateCRL メソッドは、以前は *rsa.PublicKey または *rsa.PrivateKey を受け取っていた場所で interface{} を受け取るように変更されました。これにより、将来的には他の公開鍵アルゴリズムを実装できるようになります。

更新: 変更は必要ありません。

encoding/binary パッケージ

Go 1 では、binary.TotalSize 関数は、reflect.Value ではなく interface{} 引数を受け取る Size に置き換えられました。

更新: 影響を受けるごくわずかなコードはコンパイラによってキャッチされ、手動で更新する必要があります。

encoding/xml パッケージ

Go 1 では、xml パッケージは、encoding/gob などの他のマーシャリングパッケージに設計が近づけられました。

古い Parser 型は Decoder に名前が変更され、新しい Decode メソッドがあります。 Encoder 型も導入されました。

Marshal および Unmarshal 関数は、[]byte 値で動作するようになりました。ストリームを操作するには、新しい Encoder および Decoder 型を使用します。

値をマーシャリングまたはアンマーシャリングする場合、フィールドタグでサポートされているフラグの形式は、json パッケージ (`xml:"name,flag"`) に近づくように変更されました。フィールドタグ、フィールド名、および XML 属性と要素名の間で行われる一致は、大文字と小文字を区別するようになりました。XMLName フィールドタグが存在する場合、マーシャリングされる XML 要素の名前とも一致する必要があります。

更新: go fix を実行すると、Unmarshal への一部の呼び出しを除いて、パッケージのほとんどの使用箇所が更新されます。fix ツールはフィールドタグを更新しないため、手動で修正しないと、場合によっては静かに誤動作するため、特別な注意が必要です。たとえば、古い "attr"",attr" と記述されるようになり、プレーンな "attr" は有効なままですが、意味が異なります。

expvar パッケージ

Go 1 では、RemoveAll 関数が削除されました。*MapIter 関数と Iter メソッドは、Do および (*Map).Do に置き換えられました。

更新: expvar を使用するほとんどのコードは変更する必要がありません。Iter を使用していたまれなコードは、同じ効果を達成するためにクロージャを Do に渡すように更新できます。

flag パッケージ

Go 1 では、インターフェース flag.Value がわずかに変更されました。Set メソッドは、成功または失敗を示すために、bool の代わりに error を返すようになりました。

また、時間間隔を指定する引数値に対応するために、新しい種類のフラグである Duration もあります。このようなフラグの値は、time.Duration がそれらをフォーマットする方法と同様に、単位を指定する必要があります: 10s1h30m など。

var timeout = flag.Duration("timeout", 30*time.Second, "how long to wait for completion")

更新: 独自のフラグを実装するプログラムは、Set メソッドを更新するために、わずかな手動修正が必要になります。Duration フラグは新しく、既存のコードには影響しません。

go/* パッケージ

go の下にあるいくつかのパッケージは、API がわずかに修正されました。

具体的な Mode 型が、go/scannergo/parsergo/printer、および go/doc パッケージの構成モードフラグに導入されました。

AllowIllegalChars および InsertSemis モードは、go/scanner パッケージから削除されました。これらは、Go ソースファイル以外のテキストをスキャンする場合に主に役立ちました。代わりに、text/scanner パッケージをその目的で使用する必要があります。

scannerのErrorHandlerは、Initメソッドに提供される際、インターフェースではなく単なる関数になりました。ErrorVector型は削除され、代わりに(既存の)ErrorList型が使用されるようになり、ErrorVectorのメソッドは移行されました。scannerのクライアントでErrorVectorを埋め込む代わりに、クライアントはErrorListを保持する必要があります。

go/parserパッケージで提供される解析関数のセットは、主要な解析関数であるParseFileと、いくつかの便利な関数であるParseDirParseExprに削減されました。

go/printerパッケージは、追加の設定モードであるSourcePosをサポートするようになりました。このモードが設定されている場合、プリンターは、生成された出力に元のソースコードの位置情報が含まれるように、//lineコメントを出力します。新しい型CommentedNodeを使用して、任意のast.Nodeに関連付けられたコメントを提供できます(これまでコメント情報はast.Fileのみが保持していました)。

go/docパッケージの型名は、Docサフィックスを削除することで合理化されました。PackageDocPackageに、ValueDocValueになりました。また、すべての型が一貫してNameフィールド(または型Valueの場合はNames)を持ち、Type.FactoriesType.Funcsになりました。doc.NewPackageDoc(pkg, importpath)を呼び出す代わりに、パッケージのドキュメントは次のように作成されます。

    doc.New(pkg, importpath, mode)

ここで、新しいmodeパラメータは操作モードを指定します。 AllDeclsに設定した場合、すべての宣言(エクスポートされたものだけでなく)が考慮されます。関数NewFileDocは削除され、関数CommentTextTextメソッドになりました(ast.CommentGroup)。

go/tokenパッケージでは、token.FileSetメソッドFiles(最初は*token.Fileのチャネルを返していました)は、代わりに関数引数を受け入れるイテレーターIterateに置き換えられました。

go/buildパッケージでは、APIがほぼ完全に置き換えられました。このパッケージは依然としてGoパッケージ情報を計算しますが、ビルドは実行しません。CmdScriptの型はなくなりました。(コードをビルドするには、新しいgoコマンドを使用してください。)DirInfo型はPackageという名前になりました。FindTreeScanDirは、ImportImportDirに置き換えられました。

更新goのパッケージを使用するコードは手動で更新する必要があります。コンパイラは不正な使用を拒否します。go/doc型のいずれかとともに使用されるテンプレートは手動での修正が必要になる場合があります。名前が変更されたフィールドはランタイムエラーを引き起こします。

ハッシュパッケージ

Go 1では、hash.Hashの定義に新しいメソッドBlockSizeが含まれています。この新しいメソッドは主に暗号化ライブラリで使用されます。

hash.HashインターフェースのSumメソッドは、ハッシュ値が追加される[]byte引数を受け取るようになりました。以前の動作は、呼び出しにnil引数を追加することで再現できます。

更新hash.Hashの既存の実装では、BlockSizeメソッドを追加する必要があります。入力を1バイトずつ処理するハッシュは、BlockSizeを1を返すように実装できます。go fixを実行すると、hash.Hashのさまざまな実装のSumメソッドの呼び出しが更新されます。

更新:このパッケージの機能は新しいものであるため、更新は必要ありません。

httpパッケージ

Go 1では、httpパッケージがリファクタリングされ、いくつかのユーティリティがhttputilサブディレクトリに配置されました。これらの部分はHTTPクライアントではめったに必要ありません。影響を受ける項目は次のとおりです。

Request.RawURLフィールドは削除されました。これは歴史的な遺物でした。

HandleおよびHandleFunc関数、およびServeMuxの同様の名前のメソッドは、同じパターンを2回登録しようとするとパニックになるようになりました。

更新go fixを実行すると、影響を受けるいくつかのプログラムが更新されますが、RawURLの使用は手動で修正する必要があります。

imageパッケージ

imageパッケージには、いくつかのマイナーな変更、再配置、および名前の変更がありました。

ほとんどのカラー処理コードは、独自のパッケージであるimage/colorに移動されました。移動した要素については、対称性が生じます。たとえば、image.RGBAの各ピクセルはcolor.RGBAです。

古いimage/ycbcrパッケージは、名前の変更とともにimageおよびimage/colorパッケージにまとめられました。

古いimage.ColorImage型は依然としてimageパッケージにありますが、image.Uniformに名前が変更されました。一方、image.Tiledは削除されました。

この表に、名前の変更をリストします。

古い 新しい

image.Color color.Color
image.ColorModel color.Model
image.ColorModelFunc color.ModelFunc
image.PalettedColorModel color.Palette

image.RGBAColor color.RGBA
image.RGBA64Color color.RGBA64
image.NRGBAColor color.NRGBA
image.NRGBA64Color color.NRGBA64
image.AlphaColor color.Alpha
image.Alpha16Color color.Alpha16
image.GrayColor color.Gray
image.Gray16Color color.Gray16

image.RGBAColorModel color.RGBAModel
image.RGBA64ColorModel color.RGBA64Model
image.NRGBAColorModel color.NRGBAModel
image.NRGBA64ColorModel color.NRGBA64Model
image.AlphaColorModel color.AlphaModel
image.Alpha16ColorModel color.Alpha16Model
image.GrayColorModel color.GrayModel
image.Gray16ColorModel color.Gray16Model

ycbcr.RGBToYCbCr color.RGBToYCbCr
ycbcr.YCbCrToRGB color.YCbCrToRGB
ycbcr.YCbCrColorModel color.YCbCrModel
ycbcr.YCbCrColor color.YCbCr
ycbcr.YCbCr image.YCbCr

ycbcr.SubsampleRatio444 image.YCbCrSubsampleRatio444
ycbcr.SubsampleRatio422 image.YCbCrSubsampleRatio422
ycbcr.SubsampleRatio420 image.YCbCrSubsampleRatio420

image.ColorImage image.Uniform

imageパッケージのNew関数(NewRGBANewRGBA64など)は、4つの整数ではなく、image.Rectangleを引数として受け取るようになりました。

最後に、新しい定義済みのcolor.Color変数color.Blackcolor.Whitecolor.Opaque、およびcolor.Transparentがあります。

更新go fixを実行すると、変更の影響を受けるほぼすべてのコードが更新されます。

log/syslogパッケージ

Go 1では、syslog.NewLogger関数はlog.Loggerだけでなくエラーも返します。

更新: 影響を受けるごくわずかなコードはコンパイラによってキャッチされ、手動で更新する必要があります。

mimeパッケージ

Go 1では、mimeパッケージのFormatMediaType関数は、ParseMediaTypeと一貫性を持たせるために簡略化されました。現在では、"text""html"ではなく、"text/html"を取ります。

更新: 影響を受けるごくわずかなコードはコンパイラによってキャッチされ、手動で更新する必要があります。

netパッケージ

Go 1では、さまざまなSetTimeoutSetReadTimeout、およびSetWriteTimeoutメソッドが、それぞれSetDeadlineSetReadDeadline、およびSetWriteDeadlineに置き換えられました。接続でのアクティビティに適用されるナノ秒単位のタイムアウト値を取るのではなく、新しいメソッドは、読み取りと書き込みがタイムアウトしてブロックしなくなる絶対的な期限(time.Time値として)を設定します。

また、ネットワークアドレスのダイヤルをタイムアウトするのを簡単にする新しい関数net.DialTimeoutと、複数のリスナー間で同時にマルチキャストUDPをリッスンできるようにするnet.ListenMulticastUDPもあります。net.ListenMulticastUDP関数は、古いJoinGroupおよびLeaveGroupメソッドを置き換えます。

更新:古いメソッドを使用するコードはコンパイルに失敗し、手動で更新する必要があります。意味的な変更により、fixツールで自動的に更新することが困難になっています。

osパッケージ

Time関数は削除されました。呼び出し側はtimeパッケージのTime型を使用する必要があります。

Exec関数は削除されました。呼び出し側は、利用可能な場合はsyscallパッケージのExecを使用する必要があります。

ShellExpand関数はExpandEnvに名前が変更されました。

NewFile関数は、intではなくuintptr fdを受け取るようになりました。ファイルのFdメソッドもuintptrを返すようになりました。

基盤となるオペレーティングシステムによって値のセットが異なるため、osパッケージにはEINVALなどのエラー定数はなくなりました。一般的なエラープロパティをテストするためのIsPermissionのような新しい移植可能な関数と、ErrPermissionErrNotExistのようなGoらしい名前の新しいエラー値がいくつかあります。

Getenverror関数は削除されました。存在しない環境変数と空の文字列を区別するには、os.Environまたはsyscall.Getenvを使用してください。

Process.Waitメソッドはオプション引数を削除し、関連する定数はパッケージから削除されました。また、関数Waitは削除されました。Process型のメソッドのみが残っています。

Process.Waitによって返されるWaitmsg型は、プロセスに関する情報を復元するためのアクセサーメソッドを備えた、より移植性の高いProcessState型に置き換えられました。Waitの変更により、ProcessState値は常に終了したプロセスを表します。移植性の問題によりインターフェースが他の点で簡略化されましたが、ProcessState.SysメソッドとProcessState.SysUsageメソッドによって返される値は、Unixではsyscall.WaitStatussyscall.Rusageなどの基盤となるシステム固有のデータ構造に型アサートできます。

更新go fixを実行すると、Process.Waitのゼロ引数が削除されます。その他の変更はすべてコンパイラによってキャッチされ、手動で更新する必要があります。

os.FileInfo型

Go 1はos.FileInfo型を再定義し、構造体からインターフェースに変更しました。

    type FileInfo interface {
        Name() string       // base name of the file
        Size() int64        // length in bytes
        Mode() FileMode     // file mode bits
        ModTime() time.Time // modification time
        IsDir() bool        // abbreviation for Mode().IsDir()
        Sys() interface{}   // underlying data source (can return nil)
    }

ファイルモード情報は、os.FileModeと呼ばれるサブタイプ(IsDirPerm、およびStringメソッドを持つ単純な整数型)に移動されました。

(Unixの)iノードなどのファイルモードとプロパティのシステム固有の詳細は、FileInfoから完全に削除されました。代わりに、各オペレーティングシステムのosパッケージはFileInfoインターフェースの実装を提供します。これには、ファイルメタデータのシステム固有の表現を返すSysメソッドがあります。たとえば、Unixシステム上のファイルのiノードを検出するには、次のようにFileInfoをアンパックします。

    fi, err := os.Stat("hello.go")
    if err != nil {
        log.Fatal(err)
    }
    // Check that it's a Unix file.
    unixStat, ok := fi.Sys().(*syscall.Stat_t)
    if !ok {
        log.Fatal("hello.go: not a Unix file")
    }
    fmt.Printf("file i-number: %d\n", unixStat.Ino)

(賢明ではありませんが)"hello.go"がUnixファイルであると仮定すると、iノード式は次のように縮約できます。

    fi.Sys().(*syscall.Stat_t).Ino

FileInfoの大部分の使用では、標準インターフェースのメソッドのみが必要です。

osパッケージには、ENOENTなどのPOSIXエラーのラッパーは含まれなくなりました。特定のエラー状態を確認する必要のあるいくつかのプログラムについては、IsExistIsNotExist、およびIsPermissionのブール関数があります。

    f, err := os.OpenFile(name, os.O_RDWR|os.O_CREATE|os.O_EXCL, 0600)
    if os.IsExist(err) {
        log.Printf("%s already exists", name)
    }

更新: go fix を実行すると、現在の os.FileInfo および os.FileMode API の古い同等のものを使用しているコードが更新されます。システム固有のファイルの詳細が必要なコードは、手動で更新する必要があります。os パッケージの古い POSIX エラー値を使用しているコードはコンパイルに失敗するため、これも手動で更新する必要があります。

os/signal パッケージ

Go 1 の os/signal パッケージでは、すべての着信シグナルを受信するチャネルを返していた Incoming 関数が、既存のチャネルで特定のシグナルの配信を要求する選択的な Notify 関数に置き換えられました。

更新: コードは手動で更新する必要があります。次のコードの文字通りの翻訳は

c := signal.Incoming()

次のようになります。

c := make(chan os.Signal, 1)
signal.Notify(c) // ask for all signals

ただし、ほとんどのコードでは、処理したい特定のシグナルをリストする必要があります。

c := make(chan os.Signal, 1)
signal.Notify(c, syscall.SIGHUP, syscall.SIGQUIT)

path/filepath パッケージ

Go 1 では、path/filepath パッケージの Walk 関数は、Visitor インターフェース値の代わりに、WalkFunc 型の関数値を受け取るように変更されました。WalkFunc は、ファイルとディレクトリの両方の処理を統合します。

    type WalkFunc func(path string, info os.FileInfo, err error) error

WalkFunc 関数は、開けなかったファイルやディレクトリに対しても呼び出されます。そのような場合、エラー引数は失敗を説明します。ディレクトリの内容をスキップする場合は、関数は filepath.SkipDir の値を返す必要があります。

    markFn := func(path string, info os.FileInfo, err error) error {
        if path == "pictures" { // Will skip walking of directory pictures and its contents.
            return filepath.SkipDir
        }
        if err != nil {
            return err
        }
        log.Println(path)
        return nil
    }
    err := filepath.Walk(".", markFn)
    if err != nil {
        log.Fatal(err)
    }

更新: この変更により、ほとんどのコードが簡略化されますが、微妙な影響があるため、影響を受けるプログラムは手動で更新する必要があります。コンパイラは古いインターフェースを使用しているコードをキャッチします。

regexp パッケージ

regexp パッケージが書き直されました。インターフェースは同じですが、サポートする正規表現の仕様が、古い「egrep」形式から RE2 の形式に変更されました。

更新: パッケージを使用するコードは、正規表現を手動で確認する必要があります。

runtime パッケージ

Go 1 では、パッケージ runtime によってエクスポートされていた API の多くが削除され、他のパッケージによって提供される機能が優先されました。runtime.Type インターフェースまたはその特定の具象型実装を使用しているコードは、reflect パッケージを使用する必要があります。runtime.Semacquire または runtime.Semrelease を使用しているコードは、チャネルまたは sync パッケージの抽象化を使用する必要があります。メモリ アロケータのデバッグ用に作成された安全でない API である runtime.Allocruntime.Free、および runtime.Lookup 関数には、代替機能はありません。

以前は、runtime.MemStats はメモリ割り当てに関する統計を保持するグローバル変数であり、runtime.UpdateMemStats の呼び出しはそれが最新であることを保証していました。Go 1 では、runtime.MemStats は struct 型であり、コードは現在の統計を取得するために runtime.ReadMemStats を使用する必要があります。

このパッケージには、オペレーティング システムのカーネルによって報告された、並列実行に利用できる CPU の数を返す新しい関数 runtime.NumCPU が追加されています。その値は、GOMAXPROCS の設定を知らせることができます。runtime.Cgocalls および runtime.Goroutines 関数は、runtime.NumCgoCall および runtime.NumGoroutine に名前が変更されました。

更新: go fix を実行すると、関数の名前変更に関するコードが更新されます。その他のコードは手動で更新する必要があります。

strconv パッケージ

Go 1 では、strconv パッケージは、より Go らしい、あまり C っぽくないように大幅に再設計されました。ただし、Atoi は残っています (int(ParseInt(x, 10, 0)) に似ています)。また、Itoa(x) (FormatInt(int64(x), 10)) も同様です。また、割り当てを制御できるように、文字列を返すのではなく、バイト スライスに追加する一部の関数の新しいバリアントもあります。

この表は、名前変更をまとめたものです。詳細については、パッケージのドキュメントを参照してください。

古い呼び出し 新しい呼び出し

Atob(x) ParseBool(x)

Atof32(x) ParseFloat(x, 32)§
Atof64(x) ParseFloat(x, 64)
AtofN(x, n) ParseFloat(x, n)

Atoi(x) Atoi(x)
Atoi(x) ParseInt(x, 10, 0)§
Atoi64(x) ParseInt(x, 10, 64)

Atoui(x) ParseUint(x, 10, 0)§
Atoui64(x) ParseUint(x, 10, 64)

Btoi64(x, b) ParseInt(x, b, 64)
Btoui64(x, b) ParseUint(x, b, 64)

Btoa(x) FormatBool(x)

Ftoa32(x, f, p) FormatFloat(float64(x), f, p, 32)
Ftoa64(x, f, p) FormatFloat(x, f, p, 64)
FtoaN(x, f, p, n) FormatFloat(x, f, p, n)

Itoa(x) Itoa(x)
Itoa(x) FormatInt(int64(x), 10)
Itoa64(x) FormatInt(x, 10)

Itob(x, b) FormatInt(int64(x), b)
Itob64(x, b) FormatInt(x, b)

Uitoa(x) FormatUint(uint64(x), 10)
Uitoa64(x) FormatUint(x, 10)

Uitob(x, b) FormatUint(uint64(x), b)
Uitob64(x, b) FormatUint(x, b)

更新go fixを実行すると、変更の影響を受けるほぼすべてのコードが更新されます。
§ Atoi は引き続き使用できますが、Atoui および Atof32 は使用できないため、手動で追加する必要があるキャストが必要になる場合があります。go fix ツールはそれについて警告します。

テンプレート パッケージ

template および exp/template/html パッケージは、text/template および html/template に移動しました。さらに重要なことは、これらのパッケージへのインターフェースが簡略化されたことです。テンプレート言語は同じですが、「テンプレート セット」という概念はなくなり、パッケージの関数とメソッドはそれに応じて変更され、多くの場合、削除されています。

セットの代わりに、Template オブジェクトには、名前付きテンプレート定義を複数含めることができ、事実上、テンプレート呼び出しの名前空間を構築します。テンプレートは、それに関連付けられている他のテンプレートを呼び出すことができますが、関連付けられているテンプレートのみを呼び出すことができます。テンプレートを関連付ける最も簡単な方法は、それらを一緒に解析することです。これは、パッケージの新しい構造で簡単になります。

更新: インポートは fix ツールによって更新されます。単一テンプレートの使用は、それ以外ではほとんど影響を受けません。連携して複数のテンプレートを使用するコードは、手動で更新する必要があります。text/template のドキュメントの が参考になります。

testing パッケージ

testing パッケージには、ベンチマーク関数への引数として渡される型 B があります。Go 1 では、B には、T のメソッドと同様に、ロギングと失敗レポートを可能にする新しいメソッドがあります。

func BenchmarkSprintf(b *testing.B) {
    // Verify correctness before running benchmark.
    b.StopTimer()
    got := fmt.Sprintf("%x", 23)
    const expect = "17"
    if expect != got {
        b.Fatalf("expected %q; got %q", expect, got)
    }
    b.StartTimer()
    for i := 0; i < b.N; i++ {
        fmt.Sprintf("%x", 23)
    }
}

更新: 既存のコードは影響を受けませんが、println または panic を使用するベンチマークは、新しいメソッドを使用するように更新する必要があります。

testing/script パッケージ

testing/script パッケージは削除されました。それはゴミでした。

更新: 影響を受けるコードはおそらくありません。

unsafe パッケージ

Go 1 では、関数 unsafe.Typeofunsafe.Reflectunsafe.Unreflectunsafe.New、および unsafe.NewArray が削除されました。これらの関数は、reflect パッケージによって提供されるより安全な機能を複製していました。

更新: これらの関数を使用するコードは、reflect パッケージを使用するように書き直す必要があります。encoding/gob および プロトコル バッファ ライブラリ への変更は、例として役立つ可能性があります。

url パッケージ

Go 1 では、url.URL 型のいくつかのフィールドが削除または置換されました。

String メソッドは、URL のすべてのフィールドを必要に応じて使用して、エンコードされた URL 文字列を予測どおりに再構築するようになりました。結果の文字列には、パスワードもエスケープされなくなります。

Raw フィールドは削除されました。ほとんどの場合、代わりに String メソッドを使用できます。

古い RawUserinfo フィールドは、*net.Userinfo 型の User フィールドに置き換えられています。この型の値は、新しい net.User 関数と net.UserPassword 関数を使用して作成できます。EscapeUserinfo 関数と UnescapeUserinfo 関数もなくなりました。

RawAuthority フィールドは削除されました。同じ情報は Host フィールドと User フィールドで利用できます。

RawPath フィールドと EncodedPath メソッドは削除されました。ルート化された URL (スキーマに続くスラッシュ) のパス情報は、Path フィールドでデコードされた形式でのみ利用可能になりました。場合によっては、エンコードされたデータは、デコード処理で失われた情報を取得するために必要な場合があります。これらの場合は、URL の作成元のデータにアクセスして処理する必要があります。

"mailto:dev@golang.org?subject=Hi" のように、ルート化されていないパスを持つ URL も異なる方法で処理されます。OpaquePath ブール フィールドは削除され、このような URL のエンコードされたパスを保持するために新しい Opaque 文字列フィールドが導入されました。Go 1 では、引用された URL は次のように解析されます。

    URL{
        Scheme: "mailto",
        Opaque: "dev@golang.org",
        RawQuery: "subject=Hi",
    }

新しい RequestURI メソッドが URL に追加されました。

ParseWithReference 関数は ParseWithFragment に名前が変更されました。

更新: 古いフィールドを使用するコードはコンパイルに失敗するため、手動で更新する必要があります。セマンティックの変更により、fix ツールが自動的に更新することが困難になります。

go コマンド

Go 1 では、Go パッケージとコマンドを取得、ビルド、インストールするためのツールである go コマンドが導入されています。go コマンドは makefile を廃止し、代わりに Go ソース コードを使用して依存関係を見つけ、ビルド条件を決定します。ほとんどの既存の Go プログラムでは、ビルドに makefile が必要なくなります。

go コマンドの入門書については Go コードの書き方 を参照し、詳細については go コマンドのドキュメントを参照してください。

更新: Go プロジェクトの古い makefile ベースのビルド インフラストラクチャ (Make.pkgMake.cmd など) に依存するプロジェクトは、Go コードのビルドに go コマンドを使用するように切り替え、必要に応じて、補助的なビルド タスクを実行するように makefile を書き直す必要があります。

cgo コマンド

Go 1 では、cgo コマンドは、//export 行を含むパッケージ用に生成される別の _cgo_export.h ファイルを使用します。_cgo_export.h ファイルは、C プリアンブル コメントで始まるため、エクスポートされた関数定義はそこで定義された型を使用できます。これにより、プリアンブルが複数回コンパイルされるため、//export を使用するパッケージは、C プリアンブルに関数定義や変数初期化を記述してはなりません。

パッケージ化されたリリース

Go 1 に関連する最も重要な変更点の 1 つは、事前にパッケージ化されたダウンロード可能なディストリビューションが利用できるようになったことです。これらは、アーキテクチャとオペレーティング システムの多くの組み合わせ (Windows を含む) で利用可能であり、リストは拡大する予定です。インストールの詳細については はじめに ページに説明されており、ディストリビューション自体は ダウンロード ページ にリストされています。