私はこれがどれほど視覚的に均一に見えるかが好きです。

const OldAPI => NewPackage.API
func  OldAPI => NewPackage.API
var   OldAPI => NewPackage.API
type  OldAPI => NewPackage.API

しかし、ほとんどの要素をほぼ徐々に動かすことができるので、おそらく最も単純です
解決策は、型に=を許可するだけです。

const OldAPI = NewPackage.API
func  OldAPI() { NewPackage.API() }
var   OldAPI = NewPackage.API
type  OldAPI = NewPackage.API

それで、最初に、私はその素晴らしい記事に感謝したいと思いました。 最良の解決策は、代入演算子を使用して型エイリアスを導入することだと思います。 これは、新しいキーワード/演算子を必要とせず、使い慣れた構文を使用し、大規模なコードベースのリファクタリングの問題を解決するはずです。

Russの記事が指摘しているように、エイリアスのようなソリューションは、 https： //github.com/golang/go/issues/17746とhttps://github.com/golang/go/issues/17784を適切に解決する必要があり

その記事を書いてくれてありがとう。

代入演算子を使用した型のみのエイリアスが最適だと思います。

type OldAPI = NewPackage.API

私の理由：

• 簡単です。
  代替ソリューション=>オペランドに基づいて微妙に異なる意味を持つことは、Goにとって場違いだと感じます。
• それは焦点を絞って保守的です。
  タイプに関する目前の問題は解決されており、一般化されたソリューションの複雑さを想像する必要はありません。
• それは美的です。
  私はそれがより楽しいように見えると思います。

上記のすべて：結果はシンプルで、焦点が絞られ、保守的で、美的であるため、Goの一部であることが簡単に想像できます。

ソリューションがタイプのみに制限される場合、構文

type NewFoo = old.Foo

@rscの記事で説明したように、すでに前に検討したように、私には非常に良さそうです。

定数、変数、関数に対して同じことを実行できるようにしたい場合、私の好みの構文は（以前に提案されたように）です。

package newfmt

import (
    "fmt"
)

// No renaming.
export fmt.Printf // Note: Same as `export Printf fmt.Printf`.

export (
        fmt.Sprintf
        fmt.Formatter
)

// Renaming.
export Foo fmt.Errorf // Foo must be exported, ie. `export foo fmt.Errorf` would be invalid.

export (
    Bar fmt.Fprintf
    Qux fmt.State
)

前に説明したように、欠点は、新しいトップレベルのみのキーワードが導入されることです。これは、技術的に実現可能であり、完全な下位互換性があるにもかかわらず、明らかに厄介です。 インポートのパターンを反映しているので、この構文が好きです。 輸入が許可されているのと同じセクションでのみ輸出が許可されるのは当然のことのように思われます。 パッケージ句と任意の変数、型、定数、または関数TLDの間。

名前変更識別子はパッケージスコープで宣言されますが、新しい名前

var v = Printf // undefined: Printf.
var Printf int // Printf redeclared, previous declaration at newfmt.go:8.

インポートパッケージでは、（newftmの）パッケージブロックの他のエクスポートされた識別子と同様に、名前変更識別子が通常どおり表示されます。

package foo

import "newfmt"

type bar interface {
    baz(qux newfmt.Qux) // qux type is identical to fmt.State.
}

結論として、このアプローチはnewfmtに新しいローカル名バインディングを導入しません。これにより、＃17746で説明した問題の少なくとも一部が回避され、＃17784が完全に解決されると思います。

私の最初の好みは、タイプのみのtype NewFoo = old.Fooです。

より一般的な解決策が必要な場合は、 @ cznicに同意しexportキーワードが正しい意味を伝えているとは思いません。 構文もセマンティクスもimport反映していません。 aliasどうですか？

@cznicが新しい名前を宣言するパッケージにアクセスできるようにしたくない理由は理解していますが、少なくとも私には、その制限は予期せぬ人工的なものだと感じています（ただし、その背後にある理由は完全に理解しています）。

[1]私はUnixを20年近く使用していますが、最初の試行ではまだシンボリックリンクを作成できません。 そして、私は通常、マニュアルを読んだ後、2回目の試行でも失敗します。

追加の制約を提案したいと思います。標準ライブラリ型の型エイリアスは、標準ライブラリでのみ宣言できます。

私の推論は、カスタムの命名規則に合うように標準ライブラリの概念の名前を変更したコードを操作したくないということです。 また、標準ライブラリに戻ってしまう複数のパッケージにまたがるエイリアスの長いスパゲッティチェーンを扱いたくありません。

@iand ：この制約により、この機能を使用して何かを標準ライブラリに移行することがブロックされます。 適切な例として、現在のContextの標準ライブラリへの移行。 Contextの古い家は、標準ライブラリのContextエイリアスになるはずです。

@quentinmitそれは残念ながら本当です。 また、このCLhttps：//go-review.googlesource.com/#/c/32145/のgolang.org/x/image/drawのユースケースも制限されます。

私の本当の懸念は、 interface{}やerrorようなものをエイリアシングする人々にあります

新しいオペレーターを導入することになった場合は、 ~を提案したいと思います。 英語では、一般的に「類似」、「ほぼ」、「約」、または「周辺」を意味すると理解されています。 上記の@ 4adで述べたように、 =>は、方向性が混乱する非対称演算子です。

例えば：

const OldAPI ~ NewPackage.API
func  OldAPI ~ NewPackage.API
var   OldAPI ~ NewPackage.API
type  OldAPI ~ NewPackage.API

@iand右側をパッケージ修飾識別子に制限すると、特定の懸念が解消されます。

また、現在のパッケージのどの型にも、またはmap[string]map[int]interface{}ような長い型式のエイリアスを設定できないことも意味します。 しかし、これらの使用は、段階的なコード修復の主な目的とは何の関係もないので、おそらく大きな損失ではありません。

@ cznic 、 @ iand 、その他： _ことに注意してください。 それらは機能の説明を複雑にし、機能のすべてのユーザーに認知的負荷を追加します。制限を忘れた場合、機能するはずだと思ったものが機能しない理由をパズルで解く必要があります。

架空の誤用のみを理由として、意匠の試行に制限を実装することはしばしば間違いです。 これはエイリアス提案の議論で起こり、トライアルのエイリアスは記事からのio.ByteBuffer => bytes.Buffer変換を処理できなくなりました。 記事を書く目的の一部は、処理できるようにしたいことがわかっているいくつかのケースを定義して、不注意にそれらを制限しないようにすることです。

別の例として、非ポインター型のレシーバーを禁止したり、非構造体型のメソッドを禁止したりするために、誤用の引数を作成するのは簡単です。 これらのいずれかを実行した場合、String（）メソッドを使用して列挙型を作成してそれ自体を印刷することはできません。また、 http.Headersプレーンマップにしてヘルパーメソッドを提供することもできません。 多くの場合、誤用を想像するのは簡単です。 説得力のある積極的な使用は、表示されるまでに時間がかかる可能性があり、実験用のスペースを作成することが重要です。

さらに別の例として、ポインターと値のメソッドの元の設計と実装では、Tと* Tのメソッドセットが区別されませんでした。* Tがある場合は、値メソッド（レシーバーT）を呼び出すことができ、 Tの場合、ポインタメソッド（レシーバー* T）を呼び出すことができます。 これは単純で、説明する制限はありませんでした。 しかし、実際の経験から、値に対するポインターメソッドの呼び出しを許可すると、特定のクラスの紛らわしい驚くべきバグが発生することがわかりました。 たとえば、次のように書くことができます。

var buf bytes.Buffer
io.Copy(buf, reader)

io.Copyは成功しますが、bufには何も含まれません。 そのプログラムが正しく実行されなかった理由を説明するか、そのプログラムがコンパイルされなかった理由を説明するかを選択する必要がありました。 いずれにせよ、質問がありましたが、私たちは誤った実行を避ける側に落ちました。 それでも、デザインに穴が開いている理由についてのFAQエントリを

繰り返しますが、制限により複雑さが増すことを忘れないでください。 すべての複雑さのように、制限には重要な正当化が必要です。 設計プロセスのこの段階では、特定の設計に適している可能性のある制限について考えるのは良いことですが、制限のない単純な設計を実際に経験した後でのみ、制限が十分なメリットをもたらすかどうかを理解するのに役立つ可能性があります。その費用を支払うために。

また、Go 1.9サイクルの開始時（理想的にはサイクルが開始する日）に、何を試すかについて暫定的な決定を下し、実験の準備ができていることを願っています。 実験する時間が増えると、特定の制限が説得力があるかどうかを学ぶ機会など、多くの利点があります。 エイリアスの1つの間違いは、Go1.8サイクルの終わり近くまで完全な実装をコミットしなかったことです。

元のエイリアス提案についての1つのことは、意図されたユースケース（リファクタリングを有効にする）では、エイリアスタイプの実際の使用は一時的なものにすぎないということです。 プロトバッファの例では、段階的な修復が完了すると、io.BytesBufferスタブが削除されました。

エイリアスメカニズムを一時的にのみ表示する必要がある場合、実際には言語を変更する必要がありますか？ おそらく代わりに、「エイリアス」のリストをgcに提供するメカニズムが存在する可能性があります。 gcは一時的に置換を行う可能性があり、ダウンストリームコードベースの作成者は、修正がマージされるときにこのファイル内のアイテムを徐々に削除する可能性があります。 この提案もトリッキーな結果をもたらすことを私は理解していますが、少なくとも一時的なメカニズムを奨励しています。

構文に関するバイクシェディングには参加しません（基本的には気にしません）。ただし、エイリアスの追加が決定され、それらを型に制限することが決定された場合は、少なくともvarまで一貫して拡張可能な構文を使用してください。 funcおよびconst （ type Foo = pkg.Barを除くすべての提案された構文構造はすべてを許可します）。 その理由は、 varエイリアスが違いを生むケースはまれかもしれないと私は同意しますが、それらが存在しないとは思わないので、いつか追加することを決定するかもしれないと信じていますそれらも。 その時点で、すべてのエイリアス宣言に一貫性を持たせたいと思うでしょう。 type Foo = pkg.Barとvar Foo => pkg.Bar場合は悪いでしょう。

私はまた、4つすべてを持っていることについて少し議論したいと思います。 理由は

1） varには違いがvar Debug *log.Logger公開したり、 http.DefaultServeMuxなどのグローバルシングルトンを再割り当てして、ハンドラーを追加するパッケージの登録をインターセプト/削除したりすることがよくあります。

2） func Foo() { pkg.Bar() }はfunc Foo => pkg.Barと同じことをしますが、後者の意図ははるかに明確だと思います（特にエイリアスについてすでに知っている場合）。 「これは実際にここにあることを意味するものではない」と明確に述べています。 したがって、技術的には同じですが、エイリアス構文はドキュメントとして役立つ場合があります。

しかし、それは私が死ぬ丘ではありません。 後で拡張するオプションがある限り、今のところタイプエイリアスだけで問題ありません。

これが今のように書かれていてとても嬉しいです。 しばらくの間、APIの設計と安定性について私が持っていたたくさんの意見を要約しており、将来的には、人々をリンクするための簡単なリファレンスとしても役立ちます:)

ただし、ドキュメントとは異なるエイリアスでカバーされる追加のユースケースがある場合も強調したいと思います（AIUIは、この問題のより一般的な意図であり、段階的な修復を解決するための解決策を見つけることです）。 段階的な修復を可能にするというコンセプトにコミュニティが同意できればとても嬉しいですが、エイリアスとは異なる決定が下された場合は、サポートするかどうか、どのようにサポートするかについても同時に話し合う必要があると思います。 protobufのパブリックインポートや、別のソリューションを使用したドロップイン置換パッケージのx/image/drawユースケース（どちらも私の心にやや近い）などです。 @btraceyによるエイリアスのgo-tool / gcフラグの提案は、段階的な修復を比較的うまくカバーしているものの、他のユースケースでは実際には受け入れられないと私が信じている例です。 あなたは本当に使用して何かをコンパイルしようと誰もが期待することはできませんx/image/drawそれらのフラグを渡すためには、彼らはただにできるはずですgo get 。

@jba

@iand右側をパッケージ修飾識別子に制限すると、特定の懸念が解消されます。

また、現在のパッケージのどのタイプにもエイリアスを設定できないことを意味します[…]。 しかし、これらの使用は、段階的なコード修復の主な目的とは何の関係もないので、おそらく大きな損失ではありません。

パッケージ内での名前の変更（たとえば、より慣用的な名前や一貫性のある名前）は、確かに合理的に実行したいリファクタリングの一種であり、パッケージが広く使用されている場合は、段階的な修復が必要になります。

パッケージ修飾名のみに制限するのは間違いだと思います。 （エクスポートされた名前のみに制限する方が許容できる場合があります。）

@btracey

おそらく代わりに、gcに「エイリアス」のリストを提供するメカニズムがある可能性があります。 gcは一時的に置換を行う可能性があり、ダウンストリームコードベースの作成者は、修正がマージされるときにこのファイル内のアイテムを徐々に削除する可能性があります。

gcのメカニズムは、コードが修復プロセス中にgcのみビルド可能であること、またはメカニズムが他のコンパイラーによってサポートされる必要があることを意味します（例： gccgoとllgo ）も。 すべての実装でサポートされなければならない「非言語変更」メカニズムは、事実上の言語変更です。これは、ドキュメントが不十分なメカニズムにすぎません。

コンパイラだけでなく、 @ btraceyと@bcmills ：教祖や他の人々が構築したものなど、ソースコードを分析するツール。 どのようにスライスしても、それは確かに言語の変化です。

わかりました、ありがとう。

もう1つの可能性は、 constsを除くすべてのエイリアスです（

constsの場合、 =>は、実際には=を記述するためのより長い方法です。 タイプや変数のように、新しいセマンティクスはありません。 funcsのように保存されたキーストロークはありません。

それは少なくとも＃17784を解決するでしょう。

反論は、ツールがケースを異なる方法で処理する可能性があり、それが意図の指標になる可能性があるということです。 これは良い反論ですが、まったく同じことを行うには基本的に2つの方法があるという事実を上回るとは思いません。

とは言うものの、今のところ私はタイプエイリアスだけで大丈夫です、それらは確かに最も重要です。 私は@Meroviusに間違いなく同意しです。ただし、それらがしばらくの間発生しない場合でも同様です。

「C」や「unsafe」の場合と同様に、インポートの背後にエイリアスを非表示にして、その使用をさらに阻止するのはどうでしょうか。 同様に、エイリアスの構文は冗長で、リファクタリングを進めるための足場として目立つようにしたいと思います。

デザインスペースを少し開放する試みとして、ここにいくつかのアイデアがあります。 彼らは肉付けされていません。 それらはおそらく悪いおよび/または不可能です。 希望は主に他の人に新しい/より良いアイデアを引き起こすことです。 そして、興味があれば、さらに探求することができます。

（1）と（2）の動機付けとなるアイデアは、エイリアスの代わりに変換を使用することです。 ＃17746では、エイリアスが同じタイプの複数の名前を持つことに関する問題に遭遇しました（または、エイリアスを#defineのように考えるか、ハードリンクのように考えるかに応じて、同じ名前を綴る複数の方法）。 変換を使用すると、タイプを区別することで回避できます。

1. さらに自動変換を追加します。

fmt.Println("abc")を呼び出すか、 var e interface{} = "abc"書き込むと、 "abc"は自動的にinterface{}変換されます。 type T struct { S }を宣言し、Tにプロモートされていないメソッドがない場合、コンパイラが必要に応じて、他の構造体内を再帰的に含めて、SとTの間で自動的に変換するように言語を変更できます。 Tは、段階的なリファクタリングの目的で、Sの事実上のエイリアス（またはその逆）として機能する可能性があります。

1. 新しい「見た目」の種類のタイプを追加します。

type T ~Sが、「Sのように見える」型である新しい型Tを宣言します。 より正確には、Tは「タイプSとの間で変換可能な任意のタイプ」です。 （いつものように、構文については後で説明できます。）インターフェイスタイプと同様に、Tにはメソッドを含めることはできません。 基本的にTで何でもするためには、それをS（またはSとの間で変換可能なタイプ）に変換する必要があります。 インターフェイスタイプとは異なり、「具象タイプ」はありません。SからTおよびTからSへの変換には、表現の変更は含まれません。 段階的なリファクタリングの場合、これらの「見た目」タイプにより、作成者は古いタイプと新しいタイプの両方を受け入れるAPIを作成できます。 （「Lookslike」タイプは、基本的に非常に制限された単純化された共用体タイプです。）

1. タイプタグ

ボーナス超恐ろしいアイデア。 （これがひどいことをわざわざ言わないでください-私はそれを知っています。私は他の人に新しいアイデアを刺激しようとしているだけです。）タイプタグ（構造体タグなど）を導入し、特別なタイプタグを使用して設定した場合はどうなりますか？ type T S "alias:\"T\""などのエイリアスを制御します。 タイプタグには他の用途もあり、単に「このタイプはエイリアスである」だけでなく、パッケージ作成者によるエイリアスの指定の範囲を提供します。 たとえば、コードの作成者は埋め込み動作を指定できます。

エイリアスを再試行する場合は、「iotaの機能」や「埋め込みの機能」の問題と同様に、「godocの機能」について検討する価値があるかもしれません。

具体的には、

type  OldAPI => NewPackage.API

NewPackage.APIにはドキュメントコメントがあります。「typeOldAPI」の横にそのコメントをコピーして貼り付けるか、コメントを付けないでおくか（godocが自動的にリンクを提供するか、自動的にコピーして貼り付けます）、または他の慣習はありますか？

主な動機は段階的なコード修復をサポートすることであり、サポートする必要がありますが、マイナーなユースケース（具体的な提案であるため、エイリアスの提案に戻る）は、単一の関数を提示するときに二重の関数呼び出しのオーバーヘッドを回避することです。複数のビルドタグに依存する実装に支えられています。 今は手を振っているだけですが、最近のhttps://groups.google.com/d/topic/golang-nuts/wb5I2tjrwoc/discussionでエイリアスが役に立ったと思い

@nigeltao re godoc、私は思う：

関係なく、常にオリジナルにリンクする必要があります。

エイリアスにドキュメントがある場合は、関係なくそれらを表示する必要があります。

エイリアスにドキュメントがない場合、godocに元のドキュメントを表示させたくなりますが、エイリアスも名前を変更すると、タイプの名前が間違ってしまい、ドキュメントが現在のパッケージにないアイテムを参照する可能性があります。段階的なリファクタリングに使用されている場合は、Xを表示しているときに、「非推奨：Xを使用してください」というメッセージが表示される可能性があります。

ただし、ほとんどのユースケースではそれは問題ではないかもしれません。 これらはうまくいかない可能性のあるものであり、うまくいかないものではありません。 また、名前が変更されたエイリアスや誤って非推奨の警告をコピーするなど、リンティングによって検出される可能性があります。

次のアイデアが以前に投稿されたかどうかはわかりませんが、ほとんどがツールベースの「gofix」/「gorename」のようなアプローチについてはどうでしょうか。 詳細に：

• どのパッケージにも一連の書き換えルールを含めることができます（例：マッピングpkg.Ident => otherpkg.Ident ）
• これらの書き換えルールは、任意のgoファイル内の//+rewrite ...タグで指定できます。
• これらの書き換えルールは、ABI互換の変更に限定されず、他のことも可能です（ pkg.MyFunc(a) => pkg.MyFunc(context.Contex(), a) ）。
• gofixのようなツールを使用して、すべての変換を現在のリポジトリに適用できます。 これにより、パッケージのユーザーはコードを簡単に更新できます。
• 正常にコンパイルするためにgofixツールを呼び出す必要はありません。 依存関係Xの古いAPIを引き続き使用したい（Xの古いバージョンと新しいバージョンとの互換性を維持するため）ライブラリは、引き続き使用できます。 go buildコマンドは、ディスク上のファイルを変更せずに、変換（パッケージXの書き換えタグで指定）をオンザフライで適用する必要があります。

最後のステップはコンパイラを少し複雑にしたり遅くしたりするかもしれませんが、それは基本的には単なるプリプロセッサであり、とにかく書き換えルールの量は少なく保つ必要があります。 だから、今日のための十分なブレインストーミング:)

エイリアスを使用して関数呼び出しのオーバーヘッドを回避することは、コンパイラが非リーフ関数をインライン化できないことを回避するためのハックのようです。 実装の欠陥が言語仕様に影響を与えるべきではないと思います。

@josharianあなたはそれらを完全な提案として意図していませんでしたが、私に返答させてください（たとえそうであっても、あなたに触発された人は誰でも即座の批判を考慮に入れることができます）：

1. 変換は実際には問題ではないため、実際には問題を解決しません。 x/net/context.Contextは、 context.Context割り当て可能/変換可能/何でも可能です。 問題は高次の型です。 つまり、引数が割り当て可能であっても、タイプfunc (ctx x/net/context.Context)とfunc (ctx context.Context)は同じではありません。 したがって、1が問題を解決するには、 type T struct { S }は、 TとSが同じタイプであることを意味する必要があります。 つまり、結局のところ、エイリアスに異なる構文を使用しているだけです（この構文はすでに異なる意味を持っているだけです）。

2. 割り当て可能/変換可能な型は必ずしも同じメモリ表現を持っているとは限らないため、高次の型にも問題があります（同じメモリ表現を持っている場合、解釈が大幅に変わる可能性があります）。 たとえば、 uint8はuint64変換可能であり、その逆も可能です。 しかし、それは、たとえばtype T ~uint8場合、コンパイラはfunc(T)を呼び出す方法を知ることができないことを意味します。 スタックに1、2、4、または8バイトをプッシュする必要がありますか？ この問題を回避する方法はあるかもしれませんが、私にはかなり複雑に聞こえます（そしてエイリアスよりも理解するのが難しいです）。

ありがとう、@ Merovius。

1. はい、ここでインターフェースの満足度を逃しました。 そうです、これではうまくいきません。

2. 私は「同じメモリ表現を持っている」ことを念頭に置いていました。 コンバーチブルの往復は明らかにそれの正しい解明ではありません-ありがとう。

@uluyolはい、それは主にコンパイラが非リーフ関数をインライン化できないことに関するものですが、非リーフへのインライン化された呼び出しがスタックトレース、runtime.Callersなどに表示されるかどうかに関して、明示的なエイリアシングはそれほど驚くことではないかもしれません。

いずれにせよ、私が言ったように、それはマイナーな接線です。

@josharian同様の問題： [2]uintptrとinterface{}メモリ表現は同じです。 したがって、メモリ表現のみに依存することで、型の安全性を回避できます。 uint64とfloat64はどちらも同じメモリ表現を持ち、前後に変換可能ですが、どちらがどちらかわからない場合は、少なくとも本当に奇妙な結果になります。

ただし、「同じ基になるタイプ」でうまくいくかもしれません。 その意味がわからない。 たとえば、フィールドでタイプが使用されている場合、それは間違いにつながる可能性があります。 type S1 struct { T1 }とtype S2 struct { T2 } （ T1とT2が同じ基になるタイプ）がある場合、 type L1 ~T1両方とも次のように機能する可能性があります。 type S struct { L1 }ですが、 T1とT2まだ異なる（似ていますが）基になるタイプがあるため、 type L2 ~S1ではS2はありません。 S1似ており、 L2としては使用できません。

したがって、仕様の多くの場所で、「同一の型」を「同じ基になる型」​​に置き換えるか修正する必要があります。これは扱いにくく、型の安全性に予期しない結果をもたらす可能性があります。 「そっくり」タイプは、エイリアスに対する主な議論であると思われるエイリアス、IMHOよりもさらに大きな乱用と混乱の可能性があるようです。

誰かがそれのための簡単なルールを思い付くことができるならば、しかし、それはこれらの問題を持っていません、それは間違いなく代替として考慮されるべきです:)

@josharianの考えに続いて、ここに彼の番号2のバリエーションがあります。

「代替可能なタイプ」の指定を許可します。 これは、関数の引数、戻り値などで名前付き型の代わりに使用できる型のリストです。コンパイラーは、名前付き型またはその代替の引数を使用して関数を呼び出すことを許可します。 代替タイプは、指定されたタイプと互換性のある定義を持っている必要があります。 ここで互換性があるとは、宣言で他の代替タイプを許可した後の同一のメモリ表現と同一の宣言を意味します。

差し迫った問題の1つは、この関係の方向性が、依存関係グラフを反転するエイリアス提案と反対であるということです。 これだけではうまくいかないかもしれませんが、他の人がこれを回避する方法を考えるかもしれないので、ここで提案します。 1つの方法は、インポートグラフではなく、// goコメントとして代替を宣言することです。 このようにして、それらはおそらくマクロのようになります。

逆に、この方向性の逆転にはいくつかの利点があります。

• 代替可能なタイプのセットは、セマンティクスを保証するためにより適切に配置された新しいパッケージの作成者によって制御されます。
• 元のパッケージではコードを変更する必要がないため、クライアントは新しいパッケージの使用を開始するまで更新する必要はありません。

これをコンテキストリファクタリングに適用する：標準ライブラリコンテキストパッケージは、 context.Contextをgolang.org/x/net/context.Contextで置き換えることができると宣言します。 これは、context.Contextを受け入れるすべての使用法が、代わりにgolang.org/x/net/context.Contextを受け入れる可能性があることを意味します。 ただし、コンテキストを返すコンテキストパッケージ内の関数は、常にcontext.Context返します。

この提案は、埋め込み型の名前が変更されないため、埋め込みの問題（＃17746）を回避します。 ただし、埋め込み型は、代替型の値を使用して初期化できます。

@ iand @ josharianあなたは共変型の特定の変種を求めています。

@josharian 、提案をありがとう。

type T struct { S }については、エイリアスの構文が異なるように見えますが、必ずしも明確な構文であるとは限りません。

type T ~Sに関しては、エイリアスとの違いがわからないか、リファクタリングにどのように役立つかわかりません。 リファクタリング（たとえば、io.ByteBuffer-> bytes.Buffer）では、次のように記述します。

package io
type ByteBuffer ~bytes.Buffer

しかし、あなたが言うように、「基本的にTで何かを行うには、それをSに変換する必要がある」場合、io.ByteBufferで何かを行うすべてのコードはまだ壊れています。

Re type T S "alias" ：上記の@bcmillsの重要なポイントは、タイプに同等の名前を複数持つことは、スペルに関係なく言語の変更であるということです。 すべてのコンパイラは、たとえば、io.ByteBufferとbytes.Bufferが同じであることを知っている必要があります。これは、コードを分析したり、型チェックしたりするツールと同じです。 あなたの提案の重要な部分は、「多分、他の追加を前もって計画する必要がある」というようなもののように思えます。 たぶん、しかし、文字列がそれらを説明するための最良の方法であるかどうかは不明であり、明確な必要性なしに構文（Javaの一般化された注釈など）を設計したいことも不明です。 一般的な形式を持っていたとしても、導入した新しいセマンティクスのすべての影響を慎重に検討する必要があり、ほとんどの場合、すべてのツールを更新する必要がある言語の変更になります（確かに、gofmtを除く）。 結局のところ、ある種のメタ言語を作成するのではなく、必要なフォームを1つずつ作成するための最も明確な方法を見つけ続ける方が簡単なようです。

@Merovius FWIW、[2] uintptrとinterface {}は同じメモリ表現を持っていないと思います。 インターフェイス{}は[2] unsafe.Pointerであり、[2] uintptrではありません。 uintptrとポインターは異なる表現です。 しかし、あなたの一般的なポイントは正しいと思います。私たちは必ずしもそのようなものの直接変換を許可したくないということです。 つまり、interface {}から[2] * byteにも変換できますか？ ここで必要とされる以上のものです。

@jimmyfrascheと@ nigeltao 、re godoc：私たちもそれを早期に機能させる必要があることに同意します。 「新機能は、それが何であれ、コードベースのリファクタリングにのみ使用される」という仮定をハードコーディングしてはならないことに同意します。 エイリアスを使用して描画拡張パッケージを作成するのに役立つNigelのように、他の重要な用途がある場合があります。 ジミーが言ったように、非推奨のものはドキュメントコメントで明示的に非推奨としてマークされることを期待しています。 ドキュメントコメントがない場合は自動的に生成することを考えましたが、構文（一般的に言えば）からまだ明確になってはならないことを言うのは明らかではありません。 具体的な例を示すために、古いGo1.8エイリアスについて考えてみます。 与えられた

type ByteBuffer => bytes.Buffer

「ByteBufferはbytes.Bufferのエイリアスです」というドキュメントコメントを合成することもできますが、それは定義を表示するのに冗長なようです。 今日誰かが「typeXstruct {}」と書いたとしても、「Xはstruct {}の名前付き型」を合成しません。

@iand 、ありがとう。 あなたの提案では、新しいパッケージの作成者が古いパッケージから正確な定義を記述し、次に（構文を構成する）のように2つをリンクする宣言を記述する必要があるようです。

package old
type T { x int }

package new
import "old"
type T1 { x int }
substitutable T1 <- old.T

輸入の取り消しには問題があり、それ自体が目障りになる可能性があることに同意しますが、それはスキップしましょう。 この時点で、コードベースは壊れやすい状態にあるように見えます。パッケージoldに構造体フィールドを追加するように変更することで、パッケージnewを壊すことができるようになりました。 置換可能な行を考えると、T1の可能な定義は1つだけです。old.Tとまったく同じです。 2つのタイプがまだ異なる定義を持っている場合は、メソッドについても心配する必要があります。メソッドの実装も一致する必要がありますか？ そうでない場合は、インターフェイス{}にTを配置し、タイプアサーションをT1として使用してそれを引き出し、M（）を呼び出すとどうなりますか？ T1.Mはもらえますか？ T1に直接名前を付けずに、インターフェイス{M（）}として引き出し、M（）を呼び出すとどうなりますか？ あなたはTMを手に入れますか？ ソースツリーに両方の定義があることのあいまいさによって引き起こされる多くの複雑さがあります。

もちろん、置換可能な行は残りを冗長にし、タイプT1またはメソッドの定義を必要としないと言うことができます。 しかし、それは基本的に（古いエイリアス構文で） type T1 => old.Tを書くことと同じです。

インポートグラフの問題に戻ると、記事の例ではすべて古いコードが新しいコードで定義されていますが、パッケージグラフで、新しいものが古いものをインポートする必要がある場合は、リダイレクトをに配置することも同様に効果的です。移行中の新しいパッケージ。

これは、このような移行では、新しいパッケージの作成者と古いパッケージの作成者の間に有用な区別がおそらくないことを示していると思います。 最終的には、コードが新しいものに追加され、古いものから削除されることが目標です。そのため、両方の作成者（異なる場合）が関与する必要があります。 そして、この2つは、明示的（ある種のリダイレクト）または暗黙的（代替可能性の要件のように、型定義が正確に一致する必要がある）であるかどうかにかかわらず、途中でもある種の調整された互換性を必要とします。

@rscの破損シナリオは、タイプエイリアシングは双方向である必要があることを示唆しています。 以前のエイリアス提案の下でも、新しいパッケージを変更すると、そのタイプをエイリアスしたパッケージがいくつでも破損する可能性があります。

@iand定義が1つしかない場合（他の定義が「同じ」と言っているため）、それらが同期していないことを心配する必要はありません。

＃13467で、 @ joegrasseは、この提案が、複数のパッケージでcgoを使用するときに、同一のCタイプが同一のGoタイプになることを許可するメカニズムを提供するとよいと指摘しています。 これは、この問題の問題とまったく同じ問題ではありませんが、どちらの問題もタイプエイリアシングに関連しています。

エイリアスに関する提案/承認/拒否された制限/制限の概要はありますか？ 頭に浮かぶいくつかの質問は次のとおりです。

• RHSは常に完全に認定されていますか？
• エイリアスからエイリアスへのエイリアスが許可されている場合、エイリアスサイクルをどのように処理しますか？
• エイリアスはエクスポートされていない識別子をエクスポートできる必要がありますか？
• エイリアスを埋め込むとどうなりますか？ （埋め込みフィールドにどのようにアクセスしますか）
• ビルドされたプログラムでエイリアスをシンボルとして使用できますか？
• ldflags文字列インジェクション：エイリアスを参照するとどうなりますか？

@rsc会話をあまり流用したくないのですが、エイリアスの提案では、「new」が「old」に依存していたフィールドを削除すると、「old」のクライアントはコンパイルできなくなります。

ただし、代替案では、新旧両方を併用するクライアントのみが破損する可能性があると思います。 そのためには、コンパイラが「新しい」パッケージで「古い」タイプの使用を検出した場合にのみ、置換ディレクティブを検証する必要があります。

@thwdまだ良い記事はないと思います。 私のノート：

• エイリアスサイクルは問題ではありません。 パッケージ交差エイリアスの場合、インポートサイクルのため、サイクルはすでに許可されていません。 パッケージを交差させないエイリアスの場合は、明らかに禁止する必要があります。これは、初期化順序のサイクルと非常によく似ています。 個人的には、エイリアスをエイリアスに変更したいと思います。段階的な修復のユースケースに限定するべきではないと思います（上記のコメントを参照）。誰かがタイプを移動することでパッケージAが破損する可能性がある場合は、悲しいことです。エイリアス付きのパッケージB（ x/image/draw.Imageエイリアスdraw.Imageを想像してください。その後、誰かがdraw.Imageをエイリアス経由でimage.Drawに移動することを決定し、安全だと想定します。突然x/image/drawエイリアスからエイリアスへのエイリアスは許可されていないため、
• 以前、エイリアスの支持者は、エイリアスをエクスポートするエクスポートされていない識別子は、それが引き起こす可能性のある奇妙さのためにおそらく悪い考えであることに同意したと思います。 事実上、これは、エクスポートされていない識別子のエイリアスは役に立たず、完全に許可されない可能性があることを意味します。
• 埋め込みの質問であるAFAIKは、まだ解決されていません。 ＃17746には全体的な議論がありますが、エイリアスを使用して進めることが決定された場合/いつ/前にこの議論が続くことを期待しています（ただし、代替ソリューションの可能性や、段階的な修復を目標にしないという決定はまだありますまったく）

@ iand 、re「古いものと新しいものの両方を一緒に使用するクライアントだけが壊れます」、それが唯一の興味深いケースです。 それを段階的なコード修復にするのは混合クライアントです。 新しいコードのみ、または古いコードのみを使用するクライアントは、今日は機能します。

他に考慮すべきことがありますが、他の場所ではまだ言及されていません。

ここでの明確な目標は、大規模な分散型コードベースで大規模で段階的なリファクタリングを可能にすることであるため、ライブラリの所有者が、コードを変更するために不明な数のクライアントを必要とするある種のクリーンアップを実行したい場合があります（最終的に古いAPIを廃止する」ステップ）。 これを行う一般的な方法は、非推奨の警告を追加することですが、Goコンパイラには警告がありません。

コンパイラの警告がない場合、ライブラリの所有者は、リファクタリングを安全に完了できるとどのように確信できますか？

1つの答えは、ある種のバージョン管理スキームである可能性があります。これは、互換性のない新しいAPIを備えたライブラリの新しいリリースです。 その場合、おそらくバージョン管理が答えであり、タイプエイリアスではありません。

あるいは、ライブラリの作成者が、実際にクライアントのコンパイルエラーを引き起こす「非推奨の警告」を追加できるようにするのはどうでしょうか。ただし、クライアントが実行する必要のあるリファクタリングの明示的なアルゴリズムを使用します。 私は次のようなものを想像しています：

Error: os.time is obsolete, use time.time instead. Run "go upgrade" to fix this.

型エイリアスの場合、リファクタリングアルゴリズムは「OldTypeのすべてのインスタンスをNewTypeに置き換える」だけだと思いますが、微妙な点があるかもしれません。よくわかりません。

とにかく、それにより、ライブラリの作成者は、古いAPIを完全に削除する前に、コードが壊れようとしていることをすべてのクライアントに警告し、簡単に修正できるように最善を尽くすことができます。

@iainmerrickこれらには

@rscの記事で概説されているように、段階的なコード修復の問題を解決すると、2つのタイプを交換可能にする方法が必要になります（var、funcs、およびconstsには回避策が存在するため）。

これには、ツールまたは言語の変更が必要です。

2つの型を交換可能にすることは、定義上、言語の動作を変更することであるため、どのツールも、おそらく古い型のすべてのインスタンスを新しい型に書き換えることによって、コンパイラーの外部で同等性をシミュレートするメカニズムになります。 ただし、これは、stdlibコンテキストパッケージの代わりにgolang.org/x/net/contextを使用するベンダーパッケージのように、そのようなツールが所有していないコードを書き直す必要があることを意味します。 変更の仕様は、別のマニフェストファイルまたは機械可読コメントのいずれかにある必要があります。 ツールを実行しないと、ビルドエラーが発生します。 それはすべて対処するのが面倒になります。 ツールはそれが解決するのと同じくらい多くの問題を引き起こすようです。 一部が自動化されているので多少は良いですが、これらのパッケージを使用するすべての人が対処しなければならない問題は依然としてあります。

言語が変更された場合、コードはそのメンテナによって変更されるだけでよく、ほとんどの人にとって、物事はうまく機能します。 メンテナを支援するツールはまだオプションですが、ソースが仕様であり、パッケージのメンテナだけがそれを呼び出す必要があるため、はるかに簡単です。

@griesemerが指摘したように（どこにあるのか思い出せませんが、これについては非常に多くのスレッドがあります）Goには、 byte ↔ uint8ようなもののために、そしてパッケージをインポートするときに、すでにエイリアシングがあります同じソースファイルに、異なるローカル名で2回。

言語で型を明示的にエイリアスする方法を追加することで、既存のセマンティクスを使用できるようになります。 そうすることで、実際の問題を管理可能な方法で解決します。

言語の変更はまだ大きな問題であり、多くのことを解決する必要がありますが、最終的にはここで行うのが正しいことだと思います。

私の知る限り、「部屋の中の象」の1つは、タイプエイリアスの場合、それらを導入すると、非一時的な（つまり、「非リファクタリング」）使用が可能になるという事実です。 通過時に言及されたものを見てきました（たとえば、「APIを簡素化するために異なるパッケージで型識別子を再エクスポートする」）。 以前の提案の良い伝統に遅れずについていくために、 「影響」サブセクションの下にタイプエイリアスのすべての既知の代替使用法を

追加の質問：型エイリアスが新しいパッケージの型にメソッドを追加できるかどうか（おそらくカプセル化を破ることができるかどうか）を明確にしてください。 また、新しいパッケージは古い構造体のプライベートフィールドにアクセスできますか？

追加の質問：型エイリアスが新しいパッケージの型にメソッドを追加できるかどうか（おそらくカプセル化を破ることができるかどうか）を明確にしてください。 また、新しいパッケージは古い構造体のプライベートフィールドにアクセスできますか？

エイリアスは、タイプの単なる別名です。 タイプのパッケージは変更されません。 したがって、両方の質問には当てはまりません（新しいパッケージ==古いパッケージでない限り）。

@akavel現時点では、提案はまったくありません。 しかし、Go1.8エイリアストライアル中に浮かび上がった2つの興味深い可能性を知っています。

1. エイリアス（または単にエイリアスを入力）を使用すると、他のパッケージを拡張するドロップイン置換を作成できます。 たとえば、 https：//go-review.googlesource.com/#/c/32145/ 、特にコミットメッセージの説明を参照して

2. エイリアス（または単にタイプエイリアス）を使用すると、APIサーフェスは小さいが、内部構造を改善するためのパッケージのコレクションとしての実装は大きくなりますが、クライアントがインポートして使用するパッケージは1つだけです。 https://github.com/golang/go/issues/16339#issuecomment-232813695に説明されているやや抽象的な例があり

エイリアスの根本的な目標は素晴らしいですが、それでも機能の最大の動機であるにもかかわらず、コードのリファクタリングの目標に正直ではないようです。 いくつかの提案は名前を固定することを提案しています、そして私はまだタイプがそのようなリファクタリングでそれらの表面を変えることをまだ言及していません。 エイリアスの周りでよく言及されるos.Error => errorの例でさえ、 os.ErrorはErrorではなくStringメソッドがあるという事実を無視しています。 タイプを移動して名前を変更しただけでは、エラー処理コードはすべて壊れてしまいます。 これはリファクタリング中の一般的な場所です。古いメソッドは名前が変更され、移動され、削除されます。新しいコードとの非互換性が維持されるため、新しいタイプにはしたくありません。

手伝うために、ここにシードのアイデアがあります。エイリアスではなくアダプターの観点から問題を調べた場合はどうなるでしょうか。 アダプターは、既存のタイプに代替名_およびインターフェース_を付け、元のタイプが以前に見られた場所で装飾なしで使用できます。 アダプターは、基礎となる適応型の同じインターフェースが存在すると想定するのではなく、サポートするメソッドを明示的に定義する必要があります。 これは、既存のtype foo bar動作によく似ていますが、いくつかの追加のセマンティクスがあります。

io.ByteBuffer

たとえば、一時的な「adapts」キーワードを当面使用して、 io.ByteBufferケースに対処するスケルトンの例を次に示します。

type ByteBuffer adapts bytes.Buffer

func (old *ByteBuffer) Write(b []byte) (n int, err error) {
        buf := (*bytes.Buffer)(old)
        return buf.Write(b)
}

(... etc ...)

したがって、そのアダプターを配置すると、このコードはすべて有効になります。

func newfunc(b *bytes.Buffer) { ... }
func oldfunc(b *io.ByteBuffer) { ... }

func main() {
        var newvar bytes.Buffer
        var oldvar io.BytesBuffer

        // New code using the new type obviously just works.
        newfunc(&newvar)

        // New code using the old type receive the underlying value that was adapted.
        newfunc(&oldvar)

        // Old code using the old type receive the adapted value unchanged.
        oldfunc(&oldvar)

        // Old code gets new variable adapted on the way in. 
        oldfunc(&newvar)
}

newfuncとoldfuncのインターフェースは互換性があります。 どちらも実際には*bytes.Buffer受け入れ、 oldfuncは途中で*io.BytesBufferに適応します。同じ概念が割り当てや結果などに機能します。

os.Error

コンパイラの実装は少しトリッキーですが、おそらく同じロジックがインターフェイスでも機能するように作られています。 これはos.Error => error例で、メソッドの名前が変更されたという事実を処理します。

package os

type Error adapts error

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

ただし、次のような方法があるため、このケースについてはさらに検討する必要があります。

func (v *T) Read(b []byte) (int, os.Error) { ... }`

Stringメソッドを持つ型を返すので、コードを徐々に修正できるように、通常は反対方向に適応させたいと思います。

_更新：さらに考える必要があります。_

埋め込みの問題

機能を1.8からドラッグした埋め込みバグに関しては、アダプターを使用すると、同じものの単なる新しい名前ではないため、結果が少し明確になります。アダプターが埋め込まれている場合、使用されるフィールド名はアダプターは古いロジックが機能し続けるため、フィールドにアクセスすると、基になるタイプをとるコンテキストに明示的に渡されない限り、アダプターインターフェイスが使用されます。 適応されていないタイプが埋め込まれている場合、通常は発生します。

kubernetes、docker

投稿に記載されている問題は、上記の問題のバリエーションのようであり、提案によって解決されています。

vars、consts

メソッドを直接関連付けることができないため、そのシナリオで変数や定数を適応させることはあまり意味がありません。 適応されるかどうかは彼らのタイプです。

godoc

モノがアダプタであるという事実を明確にし、適応されたモノからの独立したインターフェイスが含まれているため、通常どおりそのドキュメントを表示します。

構文

素敵なものを選んでください。 ;）

@iainmerrick @zombiezen

また、エイリアスタイプがレガシーであり、新しいタイプに置き換える必要があることを自動的に推測する必要がありますか？ golint、godoc、および同様のツールを適用して古い型を非推奨として視覚化すると、型エイリアシングの乱用が大幅に制限されます。 そして、エイリアシング機能が悪用されるという最後の懸念は解決されるでしょう。

2つの観察：

1.タイプ参照のセマンティクスは、サポートされているリファクタリングのユースケースによって異なります

Gustavoの提案は、型参照とその結果のセマンティクスのユースケースについてさらに作業する必要があることを示しています。

ロスの新しい提案には、新しい構文type OldAPI = newpkg.newAPI含まれています。 しかし、セマンティクスは何ですか？ OldAPIを従来のパブリックメソッドまたはフィールドで拡張することは不可能ですか？ 互換性を維持するために、newAPIがOldAPIのすべてのパブリックメソッドとフィールドをサポートする必要がある答えとしてyesを想定します。 プライベートフィールドとメソッドに依存するOldAPIを含むパッケージ内のコードは、パッケージの可視性制約の変更がテーブルから外れていることを前提として、パブリックnewAPIのみを使用するように書き直す必要があることに注意してください。

代替パスは、OldAPIに対して追加のメソッドを定義できるようにすることです。 これにより、すべてのパブリックな古いメソッドを提供するためのNewAPIの負担が軽減される可能性があります。 しかし、それはOldAPIをNewAPIとは異なるタイプにします。 2つのタイプの値の間で何らかの形の割り当て可能性を維持する必要がありますが、ルールは複雑になります。 フィールドの追加を許可すると、より複雑になります。

2.NewAPIを含むパッケージはOldAPIを含むパッケージをインポートできません

OldAPIを再定義するには、OldAPIの定義を含むパッケージOがパッケージNをNewAPIとともにインポートする必要があります。 これは、パッケージNがOをインポートできないことを意味します。言及されていないことは明らかですが、リファクタリングのユースケースにとって重要な制約のように思われます。

更新：パッケージNはパッケージOに依存できません。たとえば、Oをインポートするパッケージをインポートすることはできません。

@niemeyerメソッドの名前変更などの変更は、すでに徐々に可能です内部で古いメソッドを呼び出す（またはその逆）、b）すべてのユーザーを新しいメソッドに徐々に変更する、c）古いメソッドを削除する。 これをタイプエイリアスと組み合わせることができます。 これが型移動に焦点を当てている理由は、これが特定された唯一のものであり、まだ可能ではないためです。 いくつかのステップを使用する場合でも、他のすべての識別された変更が可能です（たとえば、メソッドの名前を変更せずにメソッドの引数のセットを変更する）。 表面積が少ない（理解することが少ない）修正を選択することが望ましいと思います。

@rakyll個人的には、エイリアスがリファクタリング以外の何か（優れたユースケースであるラッパーパッケージなど）に役立つと考える場合は、それらを使用するだけで、非推奨の警告は無視されます。 人工的にそれらを不自由にし、ユーザーを混乱させた人には腹を立てますが、落胆することはありません。

ある時点で、ラッパーパッケージ、protobufパブリックインポート、または内部パッケージAPIの公開を実際に検討するかどうかを議論する必要があると思います（そして、一方が繰り返すことなく、この主観的なものを最もよく議論する方法がわかりません何度も何度も読めない、他の人は「そうではない」と言っています。ここでの客観的な議論はあまりありませんが、私にはそう思われます）。

私は少なくとも（明らかに）それらは良いことだと思います。また、言語機能を追加して、それを1つのユースケースだけに人為的に制限することは悪いことだと思います。 直交する適切に設計された言語を使用すると、可能な限り少ない機能で可能な限り多くのことを実行できます。 特徴が「可能なプログラムのスパンベクトル空間」を可能な限り拡大したいので、空間に単一の点を追加するだけの特徴を追加することは私には奇妙に思えます。

タイプエイリアスの提案が作成されるときに、もう1つの少し異なるユースケースを念頭に置いてほしいと思います。

この問題で説明している主なユースケースはタイプ_replacement_ですが、タイプエイリアスは、タイプへの依存関係からコード本体を切り離すのにも非常に役立ちます。

たとえば、タイプが「不安定」であることが判明したとします（つまり、おそらく互換性のない方法で変更され続けます）。 次に、一部のユーザーは「安定した」置換タイプに移行したいと思うかもしれません。 タイプの所有者とそのユーザーが必ずしも緊密に協力したり、安定性の目的について合意したりする必要がないgithubなどでの開発を考えています。

他の例としては、ライセンスの非互換性が発見された場合など、大きなパッケージや問題のあるパッケージへの依存関係が削除されないようにするのは単一のタイプだけである場合があります。

したがって、ここでのプロセスは次のようになります。

1. タイプエイリアスを定義する
2. タイプエイリアスを使用するように、関連するコード本体を変更します
3. タイプエイリアスをタイプ定義に置き換えます。

このプロセスの最後に、2つの独立したタイプがあり、それぞれの方向に自由に進化できます。

このユースケースでは、次の点に注意してください。

• 元の型定義を含むパッケージを変更して、そこに型エイリアスを追加するオプションはありません（所有者がこれに同意する可能性が低いため）
• 元の型は非推奨ではありません（ただし、型が「切り離される」過程でコード本体でそのように見なされる場合があります）。

@Merovius古いメソッドを削除または名前変更すると、それを使用していたすべてのクライアントが一度に

ほとんどの場合、Goチームはプロジェクトを外部の関係者に包括的にするために多大な労力を費やしているため、批判は不公平だと思いますが、特定のパッケージを呼び出しているコードのすべての行にアクセスできると仮定した瞬間、それは壁に囲まれていますオープンソースコミュニティのコンテキストと一致しない庭。 壁に囲まれた庭の内部でのみ機能する言語レベルのリファクタリング機能を追加することは、控えめに言っても、異例です。

@niemeyerどうやら私は自分自身を明確にしませんでした。 いずれにせよ、古いAPIを削除することを提唱していませんでした。タイプエイリアスで有効にしたいワークフローは、名前の変更方法ですでに可能であると指摘していました（同時にかどうかは関係ありません）。 だから、あなたが何をしたいのかに関わらず、

1. 古いAPIと互換性のある新しいAPIを追加します
2. 消費者を徐々に新しいAPIに切り替えます
   3a。 すべてが移行されるか、非推奨期間が終了したら、古いAPIを削除します
   3b。 両方のAPIを永久に維持することにより、無期限の安定性を提供します（たとえば、記事のこの部分を参照）。

あなたは3a対3bを行うことについて議論しているようです。 しかし、私が指摘したのは、1。メソッド名ではすでに可能ですが、型では不可能であるということです。これがその目的です。

しかし、私は今、私があなたを誤解していると思うことに気づきました:)あなたが指摘しているかもしれませんが、os.Errorは異なるインターフェース定義であるため、動きは実際にはうまくいきません。 それは本当だと思います。 APIの削除を禁止している場合、型エイリアスを使用すると、インターフェイス型のメソッドの名前を変更できません。

たぶん、あなたは私のためにあなたのアダプターのアイデアについて何かを明確にすることができます：それはまたos.Errorとして任意のfmt.Stringerを使用することを可能にしませんか？

いずれにせよ、アダプターのアイデアは、私が少し懐疑的であっても、さらに発展させる価値があるように思われます。 しかし、可能な実装者や消費者を壊すことなく、インターフェイスを徐々にリファクタリングする方法を持つことは良い目標です。

@niemeyerはい、メソッド名が誤って変更されることについても良い点があります。 それは多くの複雑さをもたらします、そしてそれは私がここで取り組もうとしていることではありません。 error / os.Errorに言及しているコードのごく一部だけが実際にメソッドを呼び出すため、移動はメソッドの変更よりも面倒な部分でした。 メソッドの名前変更は、コードの場所を変更することとは独立した問題として扱うことができると思います。 今日移動が行われていて、パッケージの再編成をシームレスに実行できたが、古いメソッド名に固執した場合でも、それは大きな進歩になります。 この問題をコードの場所に焦点を当てることは、単純化することを目的としています。

両方の種類の変更を処理する一般的な修正があれば、それは素晴らしいことだと私は同意します。 その修正が何であるかわかりません。 特に、タイプスイッチがあなたが説明したアダプターでどのように機能するかを理解していません：タイプスイッチ中に値が何らかの形で自動的に変換されますか？ リフレクションはどうですか？ 2つの名前を持つ1つのタイプのみを持つことで、前後に自動変換する2つのタイプを持つことで発生する多くの問題を回避できます。

@rscはい、アダプターはあらゆる状況で一貫して自動的に変換されるため、タイプスイッチも同じです。 あいまいになるため、アダプターとその基礎となるタイプの両方を含むタイプスイッチは禁止します。 何かが足りないかもしれませんが、すべてのコードコンテキストは必ず適応型またはその基になる型を明示的に使用する必要があるため、リフレクションの問題はまだわかりません。 今日と同じように、それが理にかなっているのであれば、どうやってそこにたどり着いたかを知らずにinterface{}に入ることはできません。

@Merovius上記の2つのコメントは、あなたがまだ指摘していることを正確に示しています。 今日タイプを移動すると、修正が必要なコードが壊れます。 メソッドの名前を変更すると、修正が必要なコードが壊れます。 メソッドを削除し、引数を変更すると、修正が必要なコードが壊れます。 これらのいずれかの場合にコードをリファクタリングする場合、機能を継続するには、すべての呼び出しサイトで破損が発生した場合に修正をアトミックに行う必要があります。 タイプを移動できるが完全に変更されていないことを許可することは、リファクタリングの非常に限られたケースであり、IMOは言語機能を正当化しません。

@niemeyerそれは具体的なタイプを処理します。 .(interface{String() string})と.(interface{Error() string})タイプアサーション、またはインターフェイスの特定の部分が変更された場合はどうでしょうか。 チェックでは、考えられる両方の基になる型を何らかの方法で考慮する必要がありますか？

@niemeyerいいえ。メソッドの名前を変更することは非アトミックに可能です。 たとえば、メソッドをA.FooからA.Barに移動するには、次のようにします。

1. A.FooラッパーとしてメソッドA.Barを追加します
2. 任意の数のコミットを介してのみA.Barを呼び出すようにユーザーを移行します
3. 非推奨を強制するかどうかに応じて、 A.Foo削除するか、削除しないでください。

関数の変更引数は非アトミックに可能です。 たとえば、パラメータx intをfunc Foo()に追加するに

1. func FooWithInt(x int) { Foo(); // use x somehow; }追加します
2. ユーザーを移行して、任意の数のコミットを介してパラメーターを追加します
3. 非推奨を強制する意思がない場合（またはWithIntを使用することに悩まされていない場合）、これで完了です。 それ以外の場合は、Fooをfunc Foo(x int) { FooWithInt(x) }ます。
4. 任意の数のコミットを介してs/FooWithInt/Foo/gユーザーを移行します。
5. FooWithInt削除します。

移動型（厳密に言えば、変数）動きを行うには、修正ではなく、非推奨を強制する必要があります（したがって、潜在的に未知のコードのビルドを壊す、つまり、これは広くタイムリーな発表が必要です）。 ただし、そうでない場合でも、より便利な名前またはその他の便利なラッピング（x / image / drawを参照）でAPIを拡張する機能は、古いものを新しい名前で参照する機能、またはその逆の機能にも依存します。

今日の型の移動と今日の関数の名前変更の違いは、前者の場合、実際にはアトミックな変更が必要であるのに対し、後者の場合、独立したリポジトリとコミットを介して徐々に変更を加えることができるということです。 「s / Foo / Bar /を実行するコミットを行います」としてではなく、それを実行するプロセスがあります。

ともかく。 どうやら、私たちがどこにいるのかわかりません。 @rscのドキュメントは、私のPOVを伝えるのに非常に明確であり、実際にはあなたのものを取得していません:)

@rsc私は2つの合理的な答えを見ることができます。 インターフェイスが入力されたタイプ、アダプタなどを伝送する単純なものであり、インターフェイスをアサートするときに通常のセマンティクスが適用されます。 もう1つは、インターフェイスを満たさないが、基になる値は満たす場合、値が適応されない可能性があることです。 前者はより単純で、おそらく私たちが考えているリファクタリングのユースケースには十分ですが、後者はおそらく、基になる型にも型アサートできるという考えとより一致しています。

@Merovius確かに、メソッドの名前を変更することは、_実際に名前を変更しないで_、代わりに呼び出しサイトに新しいAPIを使用するように強制する限り可能です。 同様に、タイプを移動することは、_実際に移動しない限り_可能であり、代わりに呼び出しサイトに新しいAPIを使用するように強制します。 古いコードの動作を維持するために、私たちは皆、これらの両方を何年も行ってきました。

@niemeyerしかし、繰り返しになりますが、タイプの場合、適切な方法で物事を追加することさえできません。 x / image / drawを参照してください。 そして、誰もが安定性についてそのような絶対的な見方をしているわけではありません。 私自身、「6、12、…月に$ function、$ type、…がなくなるので、その時点で移行するようにしてください」と言っても問題ありません。その後、メンテナンスされていないコードを壊してしまいます。なんとかその非推奨の通知に従うことができます（誰かがAPIの長期サポートが必要だと思うなら、彼らは確かにそれを提供するために支払う誰かを見つけることができます）。 私は、ほとんどの人が安定性についてその絶対的な見方を持っていないとさえ主張します。 セマンティックバージョンの最近のプッシュを参照してください。これは、互換性を破るオプションが必要な場合にのみ本当に意味があります。 そして、ドキュメントは非常によく議論しています。その場合でも、段階的な修理を行う能力から利益を得る方法と、ダイヤモンドの依存関係の問題を本質的に解決しない場合でも、それをどのように軽減できるかについてです。

安定性に対するあなたのスタンスは絶対的であるため、段階的な修復のためにエイリアスのユースケースのほとんどを却下する可能性があります。 しかし、ほとんどの囲碁コミュニティでは、それは異なりますが、破損が発生した場合に、破損とそれらを可能な限りスムーズにするための使用が必要であると私は主張します。

@niemeyer @rsc @Merovius私はあなたの議論（そして議論全体）をフォローしてきました、そして私はその真ん中でこの投稿を露骨に叩きたいです。

問題を反復するほど、何らかの形の拡張共分散セマンティクスに近づきます。 したがって、ここで考えます。具体的なタイプからインターフェイス、およびインターフェイス間で定義されたサブタイプのセマンティクス（ "is-a"）がすでにあります。 私の提案は、インターフェースを（現在の分散ルールに従って）メソッドの引数まで再帰的に共変にすることです。

これは、現在のすべてのパッケージの問題を解決するわけではありません。 ただし、APIの「可動部分」をインターフェイスにすることができるという点で、まだ作成されていない将来のすべてのパッケージの問題を解決できます（優れた設計も促進されます）。

このようにインターフェースを（ab）使用することで、すべての要件を解決できると思います。 Go 1.0を壊していますか？ わかりませんが、そうではないと思います。

@thwd 「インターフェースを再帰的に共変にする」とはどういう意味かをより正確に定義する必要があると思います。 通常、サブタイピングでは、メソッド引数は反変の方法で変更する必要があり、結果は共変の方法で変更されます。 また、あなたが言っていることから、これは具体的な（非インターフェース）タイプの既存の問題を解決しません。

@thwd私は同意しすべてをインターフェースにする必要があります（ある時点で何を移動/変更したいかわからないため）。すべて、それは良いデザインです（私はそれをJavaで見ました。それは私を悪化させます）。 何かが構造体である場合は、それを構造体にします。 他のすべては、パッケージに奇妙な構文オーバーヘッドを追加し、すべての逆依存関係を追加するだけで、実質的にメリットはありません。 それはあなたが始めたときに正気を保つ唯一の方法でもあります。 単純なものから始めて、後でもっと一般的なものに移ります。 私がこれまでに見たAPIの多くの複雑さは、APIの設計を考えすぎて、これまでに必要とされるよりもはるかに一般的なものを計画している人々から来ています。 そして、ケースの80％（その数は明らかな嘘です）では、「クリーンなAPI設計」がないため、何も起こりません。

（明確にするために：私は共変インターフェースが良い考えではないと言っているのではありません。私はそれらがこれらの問題の良い解決策ではないと言っているだけです）

@Meroviusのポイントに加えて、私が見た多くの段階的なコード修復は、一般的に有用な非インターフェースタイプをはるかに大きなパッケージから移動するという形をとっています。 次のことを考慮してください。

package foo

type Authority struct {
  Host string
  Port int
}

時間の経過とともに、fooパッケージは大きくなり、 Authorityタイプが本当に必要な人よりも多くの責任（およびコードサイズ）を得ることになります。 作成の仕方持つので、 fooauthorityだけが含まれているパッケージをAuthorityし、既存のユーザー持つfoo.Authorityまだ作業が望ましいユースケースです。 インターフェイスタイプのみを考慮するソリューションは、ここでは役に立たないことに注意してください。

@Meroviusあなたの最後のコメントは完全に主観的なものであり、私の提案ではなく個人的に私に宛てたものです。 これはうまく終わらないので、ここでその議論をやめます。

@ griesemer @ Merovius私はあなたの両方に同意します。 ループを閉じるために、これまでの議論がサブタイプ/共分散の概念につながったことに同意することができます。 また、それを実装しても、実行時の間接参照が発生しないようにする必要があります。 それは@niemeyerが提案していたことのようなもの

@ niemeyer @ Meroviusのコメントには

古いメソッドを削除または名前変更すると、それを使用していたすべてのクライアントが一度に強制終了されます。

と

もちろん、メソッドの名前を実際に変更せず、代わりに呼び出しサイトに新しいAPIを使用するように強制しない限り、メソッドの名前を変更することは可能です。 同様に、タイプを実際に移動しない限り、タイプを移動することは可能であり、代わりに呼び出しサイトに新しいAPIを使用するように強制します。 古いコードの動作を維持するために、私たちは皆、これらの両方を何年も行ってきました。

私はそれらの声明からメロヴィクスと同じ印象を受けました—あなたはしばらくの間何かを非難し、そして最終的にそれを取り除くことに同情していないということです。 コードを無期限に機能させ続けることを約束していること。 「安定に対するあなたのスタンスは絶対的です」。 （そして、さらなる誤解を未然に防ぐために、私は「あなた」を使用して、あなたの性格ではなく、あなたのアイデアを参照しています。）

@niemeyerあなたが提案しているadapts宣言は、Haskell型クラスのinstanceと密接に関連しているようです。 それをGoに大まかに翻訳すると、次のようになります。

package os

type Error interface {
  String() string
}

instance error Error (
  func (e error) String() string { return e.Error() }
)

残念ながら（ @zombiezenが指摘しているように）、これが非インターフェースタイプにどのように役立つかは明らかではありません。

また、関数型（引数と戻り値）とどのように相互作用するかは私にはわかりません。 たとえば、 adaptsのセマンティクスは、 Contextを標準ライブラリに移行するのにどのように役立ちますか？

私はそれらの声明からメロヴィクスと同じ印象を受けました—あなたはしばらくの間何かを非難することに同情していないということです

@jbaこれらは絶対的な事実であり、絶対的な意見ではありません。 メソッドまたはタイプを削除すると、それを使用するGoコードが壊れるため、これらの変更はアトミックに行う必要があります。 ただし、私の提案は、コードの段階的なリファクタリングに関するものです。これは、ここでの主題であり、非推奨を意味します。 しかし、その非推奨のプロセスは同情の問題ではありません。 私は、それぞれ数千の実際の依存関係を持つ複数のパブリックGoパッケージと、その段階的な進化のために複数の独立したAPIを持っています。 APIを壊すとき、人々を狂わせないことが期待されるのであれば、それらをストリーミングするのではなく、バッチでそのような壊しを行うのは良いことです。 もちろん、あなたが壁に囲まれた庭に住んでいて、それを修正するためにすべての呼び出しサイトに手を差し伸べることができない限り。 しかし、私は自分自身を繰り返しています..そのすべては、より明確な方法で上記の元の提案で読むことができます。

@Merovius

個人的には、エイリアスがリファクタリング以外の何か（優れたユースケースであるラッパーパッケージなど）に役立つと考える場合は、それらを使用するだけで、非推奨の警告は無視されます。

非常に多くの新しいAPIと非推奨のAPIを含むパッケージを維持し、古い（エイリアス化された）タイプの状態を明確に説明せずにエイリアスを設定しても、コードの段階的な修復には役立たず、APIサーフェスの増加に圧倒されるだけです。 私は@niemeyerに同意します。私たちのソリューションは、APIが「非推奨」であるという自由形式のgodocテキスト以外のシグナルが現在ない分散型開発者コミュニティの要件に対処する必要があります。 古い型の非推奨化に役立つ言語機能の追加はこのスレッドのトピックであるため、当然、古い（エイリアス化された）型の状態が何であるかという疑問が生じます。

型または部分パッケージに拡張機能を提供するなど、別のテーマで型エイリアスについて説明したいと思いますが、このスレッドでは説明しません。 そのトピック自体には、検討する前に対処する必要のあるさまざまなカプセル化固有の問題があります。

特定の演算子、またはエイリアス型がいくらか置き換えられていることを示唆することは、ユーザーが切り替える必要があることをユーザーに伝えるために健全である可能性があります。 このような差別化により、ツールは置き換えられたAPIを自動的に報告できるようになります。

明確にするために、非推奨ポリシーは、標準ライブラリ外のタイプに対して技術的には不可能です。 タイプは、エイリアシングパッケージの観点からのみ古いものです。 エコシステムでこれを強制することは決してできないので、標準ライブラリのエイリアスが厳密に非推奨を意味することを望んでいます（適切な非推奨通知によって示唆されています）。

また、並行して議論する際に非推奨の概念を標準化し、コアツール（golint、godocなど）でそれらをサポートすることを提案します。 非推奨の通知がないことは、Goエコシステムの最大の問題であり、段階的なコード修復の問題よりも広範囲に及んでいます。

@rakyllコンピューターで読み取り可能な非推奨通知があるユースケースに同情しています。 私は、a）エイリアスがそれであり、b）コンパイラの警告としてそれらを発行するという概念に反対します。

a）の場合、移動以外の目的でエイリアスを生産的に使用したいという事実は別として、それは非常に少数の非推奨のセットにのみ適用されます。 たとえば、いくつかのリリースで関数からいくつかのパラメーターを削除したいとします。 新しいAPIの署名が異なるため、エイリアスを使用することはできませんが、それでも発表したいと思います。 b）の場合、IMHOコンパイラの警告は一般的に悪いものです。 これは、goがすでに行っていることとほぼ一致していると思うので、正当化する必要はないと思います。

非推奨の通知についてあなたが言っていることすべてに同意します。 これにはすでに構文がありますが、明らかに：＃10909です。したがって、より便利にするための次のステップは、godocでそれらを強調表示してツールのサポートを強化し、それらの使用法について警告するチェックを行うことです（たとえば、go vet、golint、または一緒に別のツール）。

@rakyll stdlibは、導入された場合、型エイリアスの保守的な使用から開始する必要があることに同意します。

サイドバー：

Goおよび関連ツールの非推奨コメントのステータスに気付いていない人の背景は、かなり広がっているためです。

@Meroviusが上記で述べたように、アイテムを非推奨としてマークするための標準的な規則があります。 ＃10909。https ください。

TL; DR：「非推奨：」で始まる非推奨アイテムのドキュメントに段落を作成し、置換とは何かを説明します。

非推奨のアイテムをより便利な方法で表示するというgodocの提案が受け入れられています：＃17056。

@rakyllは、非推奨のアイテムが使用されたときにgolintが警告することを提案しました：golang / lint＃238。

stdlibがstdlib内でのエイリアスの使用に関して保守的な立場を取っているとしても、タイプエイリアスの存在が（機械的に検出されたり視覚的に示されたりする方法で）古いタイプが非推奨であることを意味するべきではないと思います。それが常に実際にそれを意味する場合。

そうすることは、次のいずれかを意味します。

• 他のstdlibパッケージをスキャンして、非推奨として明示的にマークされていないタイプが他の場所でエイリアスされているかどうかを確認します
• すべてのstdlibエイリアスを自動化ツールにハードコーディングする
• 古いタイプが非推奨になったことを報告するだけで、その代替品をすでに検討している場合は、発見に役立ちません。

古いタイプが非推奨になったためにタイプエイリアスが導入された場合は、新しいタイプへの参照に関係なく、古いタイプを非推奨としてマークすることによって処理する必要があります。

これにより、よりシンプルで一般的なツールが存在できるようになります。特殊なケースを指定したり、型エイリアスについて知ったりする必要はありません。ドキュメントのコメントの「非推奨：」と一致する必要があります。

stdlibのエイリアスは非推奨のみであるという公式の、おそらく一時的なポリシーは適切ですが、標準の非推奨コメントを使用し、他の使用を禁止してコードレビューを通過させることによってのみ実施する必要があります。

@niemeyer以前の返信は、電源が切れたために失われました:(故障：

しかし、私は自分自身を繰り返しています。

FWIW、あなたの最後の返信はとても役に立ちました。 以前に思っていたよりも（そしてまだあなたに見えるかもしれないよりも）、私たちはもっと同意していると私は確信しました。 しかし、まだどこかで誤解があるようです。

しかし、私の提案は、コードの段階的なリファクタリングに関するものです。

これは論争の余地がないと思います。 :)私は最初から、あなたの提案が問題に対処するために考慮されるべき興味深い代替案であることに同意しました。 私を混乱させるのは、次のようなステートメントです。

メソッドまたはタイプを削除すると、それを使用するGoコードが壊れるため、これらの変更はアトミックに行う必要があります。

私はまだここであなたの推論が何であるか疑問に思います。 原子性の単位は単一のコミットであると理解しています。 その仮定では、メソッドまたはタイプの削除が、依存するリポジトリで最初に個別の任意の数のコミットで発生し、その後、明らかなユーザーがなくなると（そして十分な非推奨になる）、なぜあなたが確信しているのか理解できません。間隔が経過した）メソッドまたはタイプは、アップストリームのコミットで削除されます（誰も依存しなくなったため、何も壊さずに）。 私は、逆依存関係の周りに、非推奨に従わない、または見つけることができない（または合理的に修正できない）特定のあいまいさの要因があることに同意しますが、私には、目前の問題とはほとんど無関係のようです。 重大な変更を適用するときはいつでも、それをどのように調整しようとしても、その問題が発生します。

そして、公平を期すために：混乱は次のような文によって実際には助けられません

もちろん、あなたが壁に囲まれた庭に住んでいて、それを修正するためにすべての呼び出しサイトに手を差し伸べることができない限り。

私が言ったことは、これが私が主張している点であるという印象をあなたに与えたなら、私がオープンソースの立場から完全に議論しているという仮定の下で、一歩下がって、多分それを読み直してくれることを願っていますコミュニティ（私を信じていない場合は、このトピックへの以前の貢献を自由に調べてください。これは、モノレポの問題よりもコミュニティの問題のほうがはるかに多いことを常に最初に指摘します。モノレポにはこれを回避する方法があります。 、あなたが指摘したように）。

ともかく。 私はこれがあなたと同じように消耗していると思います。 でも、いつかあなたの立場を理解できるといいのですが。

同時に、protobuf publicimportsのようなものをサポートするかどうかとその方法について話します...
ある時点で、ラッパーパッケージ、protobufパブリックインポート、または内部パッケージAPIの公開を実際に検討するかどうかを議論する必要があると思います。

nit：protobufの公共輸入品を特別な二次ユースケースとして言及する必要はないと思います。 これらは、内部設計ドキュメントと公開ドキュメントの両方で明示的に言及されているように、段階的なコード修復用に設計されているため、この問題で説明されている問題の傘下にすでにあります。 また、protobuf public importsを実装するには、型エイリアスで十分だと思います。 （protoコンパイラはvarを生成しますが、論理的にはconstであるため、「var Enum_name = import.Enum_name」で十分です。）

@Merovius生産的な対応をありがとう。 いくつかのコンテキストを提供してみましょう：

私はまだここであなたの推論が何であるか疑問に思います。 原子性の単位は単一のコミットであると理解しています。 その仮定では、メソッドまたはタイプの削除が最初に別々に行われることができないとあなたが確信している理由を私は単に理解していません、

それが起こり得ないとは決して言わなかった。 一歩下がって、より明確に言い換えさせてください。

私たちはおそらく、最終目標が2つあることに同意します。つまり、動作するソフトウェアが必要なことと、ソフトウェアを改善して、正常な方法で作業を継続できるようにすることです。 後者のいくつかは変化を壊しており、前者の目標と対立しています。 つまり、緊張感があります。つまり、スイートスポットがどこにあるかにはある程度の主観性があります。 私たちの議論の興味深い部分はここにあります。

そのスイートスポットを探すのに役立つ方法の1つは、人間の介入について考えることです。 つまり、コードを機能させ続けるために手動でコードを変更する必要があることを行うと、慣性が発生します。 すべての依存コードベースの関連部分がこのプロセスを通過するまでには長い時間がかかります。 私たちは忙しい人たちに、ほとんどの場合、気にしないことをするように求めています。

そのスイートスポットを見る別の方法は、動作するソフトウェアの可能性です。 非推奨の方法を使用しないように人々にどれだけ求めてもかまいません。 簡単にアクセスでき、今ここで問題が解決する場合、ほとんどの開発者はそれを使用するだけです。 ここでの一般的な反論は次のとおりです。_ああ、でもそれが壊れたときの問題です！_しかし、それは述べられた目標に反します。

したがって、これにより、型を移動するだけでは役に立たない理由について、もう少し洞察が得られることを願っています。 人々がその新しいタイプを新しい家で実際に使用するには、人間の介入が必要です。 手動でコードを変更する手間を省くときは、近い将来再び足元で再び変更されるものではなく、_新しいタイプを使用する_介入を行うのが最善です。 リファクタリングに役立つ言語機能を追加する手間を省くと、理想的には、上記の理由により、コードを単に新しい家に移動するのではなく、新しいタイプに徐々に移動できるようになります。

説明してくれてありがとう。 私はあなたの立場をよりよく理解し、あなたの仮定に同意すると思います（つまり、人々は何があっても非推奨のものを使用するので、彼らを交換に導くために可能な限りの助けを提供することが最も重要です）。 FWIW、この問題に対処するための私の素朴な計画は（段階的な修復のためのどのソリューションを使用するかに関係なく）非推奨期間にコードをパッケージごとに自動的に移行するツールのようなgo-fixですが、私は自由に帽子を認めますそれが実際にどのように機能するか、そしてそれが実際に機能するかどうかはまだ試していません。

@niemeyer Go型システムに深刻な混乱を

このコードによって提示されるジレンマを考​​えてみましょう。

package old
import "new"
type A adapts new.A
func (a A) NewA() {}

package new
type A struct{}
func (a A) OldA() {}

package main
import (
    "new"
    "old"
    "reflect"
)
func main() {
    oldv := reflect.ValueOf(old.A{})
    newv := reflect.ValueOf(new.A{})
    if oldv.Type() == newv.Type() {
        // The two types are equal, therefore they must
        // have exactly the same method set, so either
        // oldv doesn't have the OldA method or newv doesn't
        // have the NewA method - both of which imply a contradiction
        // in the type system.
    } else {
         // The two types are not equal, which means that the
         // old adapted type is not fully compatible with the old
         // one. Any type that includes either new.A or new.B will
         // be incompatible as one of its components will likewise be
         // unequal, so any code that relies on dynamic type checking
         // will fail when presented with the type that's not using the
         // expected version.
    }
 }

リフレクトパッケージの現在の公理の1つは、2つのタイプが同じである場合、それらのreflect.Type値は等しいということです。 これは、Goのランタイム型変換の効率の基盤の1つです。 私が見る限り、これを壊さずに「adapts」キーワードを実装する方法はありません。

@rogpeppe上記の反省についての@rscとの会話を参照してください。 2つのタイプは同じではないので、reflectは真実を言い、それについて尋ねられたときにアダプターの詳細を提供します。

@niemeyer 2つのタイプが同じでない場合、パッケージ間でタイプを移動する際の段階的なコード修復をサポートできるとは思いません。 たとえば、タイプの互換性を維持する新しい画像パッケージを作成したいとします。

私たちはするかもしれません：

package newimage
import "image"
type RGBA adapts image.RGB
func (r *RGBA) At(x, y) color.Color {
    return (*image.Buffer)(r).At(x, y)
}
etc for all the methods

段階的なコード修復の目的を考えると、それを期待するのは合理的だと思います
新しいパッケージで作成されたイメージは、既存の機能と互換性があります
古い画像タイプを使用します。

議論のために、image / pngパッケージが持っていると仮定しましょう
newimageを使用するように変換されましたが、image / jpegは変換されていません。

このコードが機能することを期待する必要があると思います。

img, err := png.Decode(r)
if err != nil { ... }
err = jpeg.Encode(w, img, nil)

ただし、* newimage.RGBAではなく* image.RGBAに対して型アサートを行うため、
タイプが異なるため、AFAICSは失敗します。

タイプが* image.RGBAであるかどうかに関係なく、上記のタイプアサートを成功させたとします。
か否か。 それは現在の不変条件を壊します：

Reflect.TypeOf（x）== Reflect.TypeOf（x。（anyStaticType））

つまり、静的型アサーションを使用すると、静的型がアサートされるだけではありません。
値ですが、実際に変更されることもあります。

大丈夫だと判断したとしたら、おそらく私たちも必要だと思います
適合したタイプを、互換性のある任意のインターフェースに変換できるようにするため
適合型はサポートします。そうでない場合、新しいコードまたは古いコードのいずれかが停止します
と互換性のあるインターフェイスタイプに変換するときに機能する
彼らが使用しているタイプ。

これは別の矛盾した状況につながります：

// oldInterface is some interface with methods that
// are only supported by the old type.
type oldInterface interface {
    OldMethod()
}
var x = interface{} = newpackage.Type{}
switch x.(type) {
case oldInterface:
    // This would fail because the newpackage.Type
    // does not implement OldMethod, even though we
    // we just supposedly checked that x implements OldMethod.
    reflect.TypeOf(x).Method("OldMethod")
}

全体的に、同じであるが異なる2つのタイプがあると思います
型システムを説明するのが非常に難しく、予期しない非互換性につながる
動的型を使用するコードで。

「タイプX = Y」の提案を支持します。 説明するのは簡単で、説明しません
型システムを混乱させすぎます。

@rogpeppe ： @niemeyerの提案は、 @ josharianの以前の提案と同様に、適応型をその基本型に暗黙的に変換することだと思います。

それを段階的なリファクタリングで機能させるには、適応型の引数を使用して関数を暗黙的に変換する必要もあります。 本質的には、言語に共分散を追加する必要があります。 これは確かに不可能な作業ではありません—特に同じ基本構造を持つ型の場合、多くの言語で共分散が可能です—しかし、特にインターフェース型の場合、型システムに多くの複雑さが加わり

あなたが指摘したように、それはいくつかの興味深いエッジケースにつながりますが、それらは必ずしもそれ自体が「矛盾」しているわけではありません。

type oldInterface interface {
    OldMethod()
}
var x = interface{} = newpackage.Type{}
switch y := x.(type) {
case oldInterface:
    reflect.TypeOf(y).Method("OldMethod")  // ok
    reflect.TypeOf(x).Method("NewMethod")  // ok

    // This would fail because y has been implicitly converted to oldInterface.
    reflect.TypeOf(y).Method("NewMethod")

    // This would fail because accessing OldMethod on newpackage.Type requires
    // a conversion to oldInterface.
    reflect.TypeOf(x).Method("OldMethod")
}

// This would fail because accessing OldMethod on newpackage.Type requires
// a conversion to oldInterface.

これはまだ私には矛盾しているようです。 現在のモデルは非常に単純なものです。インターフェイス値には、明確に定義された基になる静的型があります。 上記のコードでは、その基になる型について何かを推測していますが、値を覗いてみると、推測したものとは異なります。 これは、私の見解では、言語に対する重大な（そして説明するのが難しい）変更です。

ここでの議論は終わりを告げているようです。 中@egonelbreの提案に基づいてhttps://github.com/golang/go/issues/16339#issuecomment -247536289、私は議論のリンク要約を含めるように（上部）当初発行のコメントを更新しました遠い。 要約を更新するたびに、このような新しいコメントを投稿します。

全体として、ここでの感情は、一般化されたエイリアスではなく、タイプエイリアスに対するもののようです。 おそらくGustavoのアダプタのアイデアは、型エイリアスを置き換えますが、そうではない可能性があります。 現時点では少し複雑に思えますが、おそらく議論の終わりまでに、より単純な形式に到達するでしょう。 少し長く議論を続けることをお勧めします。

可変グローバル変数が「通常はバグ」であるとはまだ確信していません（そして、それらがバグである場合、レース検出器はその種のバグを見つけるための最適なツールです）。 拡張可能な構文の欠如を正当化するためにその引数が使用される場合、init（）またはその宣言によって排他的に到達できないコード内のグローバル変数への割り当てをチェックするvet-checkが実装されることを要求します。 これを実装するのは特に難しいことではなく、実行するのはそれほど手間がかからないと思います。たとえば、すべてのgodoc.org登録パッケージを使用して、可変グローバル変数のユースケースを確認します。それらすべてをバグと考えてください。

（goが不変のグローバル変数を成長させる場合、それらはconst-declarationsの一部である必要があることも信じたいと思います。これは、概念的にはそれであり、下位互換性があるためですが、これにより、たとえば、配列型で使用できる式の種類に関する複雑さであり、さらに検討する必要があります）

Re「制限？標準ライブラリタイプのエイリアスは、標準ライブラリでのみ宣言できます。」 -特に、エイリアスの使用に関心を示している既存のパッケージであるx/image/drawのドロップインユースケースを防ぐことができます。 たとえば、ルーターパッケージなどが同様の方法でnet/httpにエイリアスを使用することも非常によく想像できます（手を振る）。

私はまた、すべての制限についての反論に同意します。つまり、私はそれらのいずれも持たないことに賛成です。

@Merovius 、可変の_exported_グローバル変数はどうですか？ パッケージ内のすべてのコードがそれを適切に処理する方法を知っているので、エクスポートされていないグローバルで問題ないかもしれないのは事実です。 エクスポートされた可変グローバルが意味をなすのはそれほど明白ではありません。 私たちは、標準ライブラリで何度もこの間違いを犯しました。 たとえば、runtime.MemProfileRateを更新する完全に安全な方法はありません。 あなたができる最善のことは、プログラムの早い段階でそれを設定し、インポートしたパッケージがメモリを割り当てている可能性のある初期化ゴルーチンを開始しないことを期待することです。 var vs constについては正しいかもしれませんが、それは別の日に任せることができます。

x / image / drawの良い点。 次回の更新時に要約に追加されます。

あなたが提起したような質問に答えるために分析できるGoコードの代表的なコーパスを集めたいと思います。 私は数週間前にこれを試み始めました、そして私はいくつかの問題に遭遇しました。 思ったより少し手間がかかりますが、そのデータセットを用意することは非常に重要であり、そこに到達することを期待しています。

@rscこのトピックについてのごGothamGoのプレゼンテーションがユーチューブに掲載されていますhttps://www.youtube.com/watch?v=h6Cw9iCDVcUと最初の投稿に良いほかになるだろう。

「タイプエイリアスの提案で対処する必要がある他の問題は何ですか？」 セクションでは、「エイリアスで名前が付けられた型でメソッドを定義できますか？」に対する回答を指定すると便利です。 難しいです。 それはセクションの法令の精神に反することを私は理解していますが、エイリアスについての多くの会話の中で、ここや他の場所で、エイリアスは必然的にこれを許可し、したがって引き起こすと信じているため、すぐに概念を拒否する人々がいることに気付きましたそれが解決するよりも問題。 これは定義に暗黙的に含まれていますが、明示的に言及すると、多くの不要な前後が短絡します。 それはエイリアスの新しい提案のエイリアスFAQに含まれているかもしれませんが、それがこのスレッドの結果である必要があります。

@Meroviusエクスポートされたパッケージグローバル

パッケージのバージョンnが与えられた場合p 、

package p
var Global = 0

バージョンn + 1では、ゲッターとセッターを導入でき、変数は非推奨になりました

package p
//Deprecated: use GetGlobal and SetGlobal.
var Global = 0
func GetGlobal() int {
    return Global
}
func SetGlobal(n int) {
   Global = n
}

バージョンn + 2は、 Globalエクスポート解除できます。

package p
var global = 0
func GetGlobal() int {
    return global
}
func SetGlobal(n int) {
   global = n
}

（演習は読者に任せます。 globalへのアクセスをn + 2のミューテックスでラップし、 GetGlobal()を廃止して、より慣用的なGlobal()を優先することもできます。）

これは迅速な修正ではありませんが、問題を軽減するため、コードの段階的な修復にはfuncエイリアス（または現在の回避策）のみが厳密に必要です。

@rsc要約から除外したエイリアスの簡単な使用

@jimmyfrascheあなたは正しいです。 ゲッターとセッターを使用するというアイデアは好きではありませんが（構造体フィールドに使用したくないのと同じように）、もちろん、あなたの分析は正しいです。

エイリアスの非修復使用（ドロップイン置換パッケージの作成など）については注意が必要ですが、var-aliasesの場合は弱くなると思います。

@Meroviusはすべての点で同意しました。 私もそれについては満足していませんが、論理v☹vに従う必要があります

@niemeyerは、古いものと新しいものの両方が同じ名前で署名が異なるメソッドを持つタイプの移行をアダプターがどのように支援するかを明確にできます。 メソッドに引数を追加したり、引数のタイプを変更したりすることは、コードベースの一般的な進化のように思われます。

@rogpeppeこれはまさに今日の出来事であることに注意してください。

type two one

これにより、 oneとtwo独立したタイプになり、 interface{}反映しているかどうかに関係なく、それが表示されます。 oneとtwo間で変換することもできます。 上記のアダプターの提案は、アダプターの最後のステップを自動化するだけです。 あなたは複数の理由で提案を気に入らないかもしれませんが、それについて矛盾することは何もありません。

@iand type two oneの場合と同様に、2つのタイプには完全に独立したメソッドセットがあるため、名前の一致について特別なことは何もありません。 古いコードベースが移行される前は、以前のタイプ（現在はアダプター）の古い署名を使用したままになります。 新しいタイプを使用する新しいコードは、新しい署名を使用します。 新しいタイプの値を古いコードに渡すと、コンパイラーは後者が前者のアダプターであることを認識し、それぞれのメソッドセットを使用するため、自動的にそれを適応させます。

@niemeyer完全に指定されていない、これらのアダプターの背後に隠れている多くの複雑さがあるようです。 この時点で、型エイリアスの単純さが彼らに有利に働くと私は思います。 私はタイプエイリアスのためだけに更新する必要があるすべてのものをリストするために座った、そしてそれは非常に長いリストである。 アダプターのリストは確かに長くなりますが、私はまだすべての詳細を完全には理解していません。 完全な提案を作成したい場合は、今のところタイプエイリアスを実行し、比較的重いアダプターについての決定を後で任せることをお勧めします（ただし、ドラゴンがそこに潜んでいないことに懐疑的です） 。

@jimmyfrascheエイリアスのメソッドに関しては、確かにエイリアスは通常のメソッド定義の制限をバイパスすることを許可しません。パッケージがタイプT1 = otherpkg.T2を定義する場合、otherpkg.T2でメソッドを直接定義できないのと同様に、T1でメソッドを定義できません。 ただし、パッケージがタイプT1 = T2（両方とも同じパッケージ内）を定義している場合、答えはあまり明確ではありません。 制限を導入することはできますが、（まだ）その必要性は明らかではありません。

トップレベルのディスカッションの概要を更新しました。 変更点：

• GothamGoビデオへのリンクを追加しました
• @jbaごとに、可能な使用法として「省略形の長い名前」を追加しました。
• @Meroviusに従って、標準ライブラリの制限に対する引数としてx / image / drawを追加しました。
• @jimmyfrascheごとに、エイリアスのメソッドに関するテキストを追加しました。

デザインドキュメントが追加されました： golang.org/design/18130-type-alias

1週間前の場合と同様に、タイプエイリアスについてはまだ一般的なコンセンサスがあるようです。 ロバートと私は、チェックインしたばかりの正式な設計ドキュメントを作成しました（上記のリンク）。

提案プロセスに続いて、この問題に関する提案についての実質的なコメントを_ここ_に投稿してください。 スペル/文法/ etcは、Gerritコードレビューページhttps://go-review.googlesource.com/#/c/34592/に移動でき

「埋め込みへの影響」を再考していただきたいと思います。 これは、段階的なコード修復のための型エイリアスの使いやすさを制限します。 つまり、 p1がタイプtype T1 = T2名前を変更し、パッケージp2が構造体にp1.T2を埋め込んだ場合、その定義をp1.T1に更新することはできません。 p3が埋め込み構造体を名前で参照する可能性があるため。 p2 、その後に切り替えることはできませんp1.T1壊すことなく、 p3 。 p3は、現在のp2を壊さずに、名前をp1.T1に更新することはできません。

これを回避する方法は、a）互換性/非推奨期間の約束を、名前で埋め込みフィールドを参照しないコードに一般的に制限するか、b）個別の非推奨ステージを追加することです。したがって、 p1追加type T1 = T2と非難するT2 、その後に、 p2 （例えば）を参照非難するs2.T2名で、すべての輸入p2修復されますそうしないと、 p2が切り替わります。

さて、理論的には、問題は無期限に再発する可能性があります。 p4はp3インポートする可能性があり、それ自体がp2からの型を埋め込みます。 p3も、2回埋め込まれたフィールドを名前で参照するために、非推奨期間が必要であるように思われますか？ その場合、最も内側の非推奨期間は微小になるか、最も外側の非推奨期間は無限になります。 しかし、問題を再帰的と見なさなくても、b）時間を計るのはかなり難しいように思われます（ p2の非推奨期間はp1非推奨期間に完全に含まれる必要がありますに少なくとも2Tを選択する必要があります。これにより、リリースが整列します）。

a）私にも実用的ではないようです。 たとえば、型に*byte.Buffer埋め込まれていて、そのフィールドを設定したい（またはそのバッファーを他の関数に渡したい）場合、名前で参照せずにそれを行う方法はありません（structinitializersを使用する場合を除く）名前がないと、互換性の保証も失われます:)）。

エイリアスとしてbyteとruneと互換性があることの魅力を理解しています。 しかし、個人的には、段階的な修復のために型エイリアスの有用性を維持することの二次的なものと考えています。 両方を取得するアイデアの（おそらく悪い）例は、エクスポートされた名前の場合、任意のエイリアスを使用して埋め込みフィールドを参照できるようにすることと、エクスポートされていない名前（本質的に同じパッケージに制限されているため、作成者の制御下にある）です。 ）現在提案されているセマンティクスを維持しますか？ はい、私もこの区別が嫌いです。 多分誰かがより良い考えを持っています。

エイリアスの@rscreメソッド

両方とも同じパッケージで定義されているタイプTのエイリアスであるタイプSがあり、Sでメソッドを定義できる場合、Tが別のパッケージで定義されているpFのエイリアスであるとしたらどうでしょうか。 それも明らかに失敗するはずですが、考慮すべきソースの強制、実装、および可読性には微妙な点があります（TがSとは異なるファイルにある場合、Tでメソッドを定義できるかどうかはすぐにはわかりません。 Tの定義）。

ルール（ type T = S場合、 Tメソッドを宣言することはできません）は絶対的であり、ソースのソースを調査しなくても、ソースのその1行から適用されることが明らかです。 S、エイリアスシチュエーションのエイリアスの場合と同じように。

さらに、ローカルの型エイリアスでメソッドを許可すると、型エイリアスと型定義の区別が曖昧になります。 とにかくメソッドはSとTの両方で定義されるので、一方にしか記述できないという制限は、表現できるものを制限しません。 それは物事をより単純でより均一に保つだけです。

@jimmyfrasche type T1 = T2を記述していて、T2が同じパッケージに含まれている場合、T2という名前はおそらく非推奨になっています。 その場合、godocでのT2の発生をできるだけ少なくする必要があります。 したがって、すべてのメソッドをfunc (T1) M()として宣言したいと思います。

@jbaは、エイリアスのメソッドがそのエイリアスで宣言されていることを報告するgodocの変更であり、ソースの可読性を変更することなく、その要件を満たします。 一般に、エイリアシングや埋め込みが含まれる場合、特に型が別のパッケージからのものである場合は、godocが型の完全なメソッドセットを表示すると便利です。 この問題は、言語セマンティクスではなく、よりスマートなツールで解決する必要があります。

@jbaその場合、エイリアスの方向を逆にしないのはなぜですか？ type T2 = T1では、同じパッケージ構造でT1メソッドを定義できます。 唯一の違いは、 reflectパッケージによって報告されるタイプ名です。エイリアスを追加する前に、名前に依存しない呼び出しサイトを名前に依存しないように修正することで、移行を開始できます。

@jimmyfrasche提案書から：

「T1はT2を記述する別の方法であるため、独自のメソッド宣言のセットはありません。代わりに、T1のメソッドセットはT2のメソッドセットと同じです。少なくとも最初の試行では、T1を次のように使用するメソッド宣言に対する制限はありません。同じ宣言でT2を使用して提供されたレシーバータイプは

メソッドレシーバータイプとしてpFを使用することは決して有効ではありません。

@mdempskyはっきりしていませんでしたが、無効だと言っていました。

私のポイントは、その特定のコード行を見るだけでは、それが有効かどうかがはっきりしないということです。

type S = T与えられた場合、 Tも調べて、別のパッケージのタイプをエイリアスするエイリアスでもないことを確認する必要があります。 唯一の利点は複雑さです。

エイリアスのメソッドを常に禁止する方が簡単で読みやすく、何も失うことはありません。 紛らわしいケースが頻繁に発生することはないと思いますが、他の場所で、または別の同等のアプローチではうまく処理できないものが得られない場合に、その可能性を紹介する必要はありません。

@Merovius

p1が型タイプT1 = T2の名前を変更し、パッケージp2がp1.T2を構造体に埋め込む場合、インポーターp3が埋め込まれた構造体を名前で参照する可能性があるため、その定義をp1.T1に更新することはできません。

多くの場合、匿名フィールドを名前付きフィールドに変更し、メソッドを明示的に転送することで、この問題を回避することができます。 ただし、これはエクスポートされていないメソッドでは機能しません。

別のオプションは、補償するために2番目の機能を追加することかもしれません。 フィールドのメソッドセットを匿名にせずに（または明示的な名前変更を使用して）採用できる場合は、基になる型が変更されてもフィールド名を変更しないでおくことができます。

あなたの例からの宣言を考えてみましょう：

package p2

type S struct {
  p1.T2
}

補正機能の1つは、「フィールドエイリアス」である可能性があります。これは、エイリアスを入力するのと同様の構文に従います。

package p2

type S struct {
  p1.T1
  T2 = T1  // field T2 is an alias for field T1.
}

var s S  // &s.T2 == &s.T1

別の補正機能は「委任」である可能性があります。これは、匿名フィールドのメソッドセットを明示的に採用します。

package p2

type S struct {
  T2 p1.T1 delegated  // T2 is a field of type T1.
  // The method set of S includes the method set of T1 and forwards those calls to field T2.
}

私はフィールドエイリアスを自分で好むと思います。なぜなら、それらは別の種類の段階的な修復も可能にするからです。ポインタエイリアスや一貫性のバグを導入せずに構造体のフィールドの名前を変更することです。

@Merovius主な問題は、タイプの名前がエイリアスによって変更された場合です。

私はこれを完全には考慮していません—かろうじて通過するだけで、ただランダムな考えです：

パッケージに名前を付けてそれを埋め込むエイリアスを導入するとどうなりますか？

それが何かを修正するかどうかはわかりませんが、ループを壊すのに時間がかかるかもしれませんか？

@bcmillsその回避策については考えていませんでした、ありがとう。 エクスポートされていないメソッドに関する警告は、実際にはめったに発生しないため、一般的に私の意見を揺るがすことはないと思います（完全に理解していない限り。それが役立つと思われる場合は、遠慮なく明確にしてください。 ）。 これ以上の変更を積み重ねることは正当化されないと思います（または良い考えです）。

@Merovius考えれば考えるほど、フィールドエイリアスのアイデアが好きになります。

メソッドを明示的に転送することは、エクスポートされたとしても面倒であり、他の種類のリファクタリングを壊します（たとえば、埋め込み型にメソッドを追加し、それを埋め込む型が同じインターフェイスを満たし続けることを期待します）。 また、構造体フィールドの名前を変更することも、コードの段階的な修復を可能にするという一般的な範囲に含まれます。

@Merovius

p1が型タイプT1 = T2の名前を変更し、パッケージp2がp1.T2を構造体に埋め込む場合、インポーターp3が埋め込まれた構造体を名前で参照する可能性があるため、その定義をp1.T1に更新することはできません。 その場合、p2はp3を壊さずにp1.T1に切り替えることはできません。 p3は、現在のp2を壊さずに、名前をp1.T1に更新することはできません。

あなたの例を理解すると、次のようになります。

package p1

type T2 struct {}
type T1 = T2

package p2

import "p1"

type S struct {
  p1.T2
  F2 string // see below
}

これは、構造体フィールドの名前を変更したい一般的なケースの特定の例にすぎないと思います。 S.F2の名前をS.F1に変更する場合も、同じ問題が当てはまります。

この特定のケースでは、ローカルタイプエイリアスでp1の新しいAPIを使用するようにパッケージp2を更新する場合があります。

package p2

import "p1"

type T2 = p1.T1

type S struct {
  T2
}

もちろん、これは長期的な解決策としては適切ではありません。 p2がエクスポートされたAPIを変更してT2名を削除する必要があるという事実を回避する方法はないと思いますが、フィールドの名前変更と同じように進行します。

「パッケージ間でのタイプの移動」に関する注意事項。 その定式化は少し問題がありませんか？

私が理解している限り、この提案では、新しい名前を介して別のパッケージにあるオブジェクト定義を「参照」することができます。

オブジェクト定義は移動しませんね。 （そもそもエイリアスを使用してコードを記述しない限り、ユーザーは、draw pkgの場合と同様に、エイリアスが参照する場所を自由に変更できます）。

@atdiar別のパッケージのタイプを参照することは、タイプを移動するステップとして使用できます。 はい、エイリアスはタイプを移動しませんが、移動するためのツールとして使用できます。

@Meroviusこれを行うと、リフレクションとプラグインが破損する可能性があります。

@atdiar申し訳ありませんが、あなたが何を言おうとしているのかわかりません。 このスレッドの元のコメント、そこにリンクされている段階的な修復に関する記事、およびこれまでの議論を読んだことがありますか？ これまで考慮されていなかった議論を議論に加えようとしているのであれば、もっと明確にする必要があると思います。

最後に、有用でよく書かれた提案。 型エイリアスが必要です。型エイリアスなしで単一のAPIを作成することには大きな問題があります。これまでのところ、それを実現するためにあまり好きではない方法でコードを作成する必要があります。 これはgov1.8に含まれている必要がありますが、手遅れになることはないので、1.9に進んでください。

@Merovius
私はパッケージ間の「タイプの移動」について明示的に話している。 オブジェクト定義を変更します。 たとえば、pkg Reflectでは、一部の情報はオブジェクトが定義されたパッケージに関連付けられています。
定義を移動すると、壊れることがあります。

@katarasそれは本当に良いドキュメントやコメントについてではなく、単に型定義を移動してはならないということです。 エイリアスの提案に感謝しているのと同じくらい、人々がそれができると思っているのではないかと心配しています。

@atdiarもう一度、元のコメントとこれまでの議論からの記事を読んでください。 移動タイプと懸念事項への対処方法は、このスレッドの主な懸念事項です。 ラスの記事があなたの懸念に適切に対処していると思わない場合は、彼の説明が満足のいくものではない理由を具体的に説明してください。 :)

@kataras私は個人的には同意しますが、この機能がどれほど重要であるかを単純に主張することは、特に役立つとは思いません。 人々の懸念に対処するために建設的な議論をする必要があります。 :)

@Meroviusドキュメントを読みました。 それは私の質問に答えません。 私は十分に明確にしたと思います。 これは、以前のエイリアス提案を実装することを思いとどまらせたのと同じ問題に関連しています。

@atdiar少なくとも、わかりません。 タイプを移動すると問題が発生するとおっしゃっています。 提案は、エイリアスを使用して段階的な修復でこのような破損を回避し、古いタイプを使用するコードがなくなるまで各逆依存関係を更新してから、古いタイプを削除する方法に関するものです。 「リフレクションとプラグイン」が壊れているというあなたの主張が、これらの仮定の下でどのように成り立つかはわかりません。 あなたが仮定に疑問を呈したいのであれば、それはすでに議論されています。

また、エイリアスが1.8に入るのを妨げる問題が、あなたの言ったことにどのように関係しているかわかりません。 私の知る限り、それぞれの問題は＃17746と＃17784です。 埋め込みの問題（私は同意しませんが、破損や反省に関連していると解釈される可能性があります）について言及している場合、それは正式な提案で扱われます（ただし、上記を参照してください、提案された解決策はもっと議論する価値があると思います）そして、あなたはそれが信じられない理由について具体的にする必要があります。

それで、申し訳ありませんが、いいえ、あなたは十分に具体的ではありませんでした。 あなたが言及している「以前のエイリアス提案の実装を思いとどまらせたのと同じ問題」の問題番号がありますか。これは、理解を助けるために、これまでに述べたことに関連していますか。 あなたが話している破損の具体例を挙げていただけますか（このアップスレッドの例を参照してください。一連のパッケージ、型定義、およびいくつかのコードを示し、提案どおりに変換したときにどのように破損するかを説明してください）。 あなたがあなたの懸念に対処したいのなら、あなたは本当に他の人が最初にそれらを理解するのを助ける必要があります。

@Meroviusでは、これらの依存関係の1つがreflect.Type.PkgPath（）を調べている推移的な依存関係の場合、どうなりますか？
これは、埋め込みの問題で発生するのと同じ問題です。

@atdiar申し訳ありませんが、これまでのこのスレッドでの議論とこの提案の内容を考慮すると、これがどのように理解できる懸念であるかはわかりません。 私は今、この特定のサブスレッドから抜け出し、あなたの異議をよりよく理解しているかもしれない他の人に、それに対処する機会を与えます。

簡潔に言い換えます。

問題は、型定義がそれ自体の場所をハードコードしているという事実を考えると、型の同等性に関するものです。
型の同等性は実行時にテストされる可能性があり、テストされるため、型の移動がいかに簡単であるかはわかりません。

この「タイプの移動」のユースケースは、離れた場所にある多くのパッケージを壊してしまう可能性があるという警告を発しているだけです。 プラグインについても同様の心配があります。

（同じように、パッケージ内のポインターのタイプを変更すると、他の多くのパッケージが壊れます。その並列処理によって状況が明確になる場合です。）

@atdiar繰り返しますが、この問題は2つのステップで型を移動することに関するものです。最初に古い場所を非推奨にし、逆の依存関係を更新してから、型を移動します。 _もちろん_タイプを移動するだけで問題が発生しますが、これはこの問題の原因ではありません。 これは、それを行うための段階的なマルチステップソリューションを可能にすることです。 ここで提案されたソリューションのいずれかがこのマルチステッププロセスを有効にしないという懸念がある場合は、正確に、段階的な修復コミットの合理的なシーケンスが破損を防ぐことができない状況を説明してください。

@niemeyer

これにより、1つと2つの独立したタイプが作成され、インターフェイス{}を反映するかどうかに関係なく、それが
分かりますか。 1と2の間で変換することもできます。 上記のアダプターの提案はそれを最後にします
アダプターの自動ステップ。 あなたは複数の理由で提案を気に入らないかもしれませんが、何もありません
それについて矛盾している。

間で変換することはできません

 func() one

と

func() two

@Meroviusおそらく、

明確にするために、私はエイリアスの提案に反対しているのではなく、「パッケージ間でタイプを移動する」という定式化に反対しています。これは、まだ安全であることが証明されていないユースケースを意味します。

@jimmyfrasche re予測可能性のメソッドオンエイリアスの妥当性：

func (t T) M()が有効な場合もあれば、無効な場合もあります。 人々はこれらの境界をあまり頻繁に押し出さないので、それはあまり出てきません。 つまり、実際にはうまく機能します。 https://play.golang.org/p/bci2qnldej。 いずれにせよ、これは_可能性のある_制限のリストにあります。 考えられるすべての制限と同様に、複雑さが増すため、その複雑さを追加する前に、具体的な実世界の証拠を確認する必要があります。

@Merovius 、名前の再埋め込み：

私は状況が完全ではないことに同意します。 ただし、io.ByteBufferへの参照でいっぱいのコードベースがあり、それをbytes.Bufferに移動したい場合は、導入できるようにしたいと思います。

package io
type ByteBuffer = bytes.Buffer

io.ByteBufferへの既存の参照を更新せずに。 タイプ定義をエイリアスに置き換えた結果、io.ByteBufferが埋め込まれているすべての場所で、フィールドの名前が自動的にBufferに変更された場合、私は世界を壊し、段階的な修復はありません。 対照的に、埋め込まれたio.ByteBufferの名前がまだByteBufferである場合は、使用法を一度に1つずつ更新して、段階的に修復することができます（複数の手順を実行する必要がある可能性がありますが、これも理想的ではありません）。

これについては、＃17746である程度詳しく説明しました。 私はもともと、埋め込まれたio.ByteBufferエイリアスの名前がBufferであるという側にいましたが、上記の議論は私が間違っていると確信しました。 特に@jimmyfrascheは、埋め込まれたものの定義に応じてコードが変更されないことについて、いくつかの良い議論をしました。 埋め込まれたエイリアスを完全に禁止するのは難しいと思います。

あなたの例のp2には回避策があることに注意してください。 p2がio.ByteBufferを参照せずにByteBufferという名前の埋め込みフィールドを本当に必要とする場合は、次のように定義できます。

type ByteBuffer = bytes.Buffer

次に、io.ByteBufferの代わりにByteBuffer（つまり、p2.ByteBuffer）を埋め込みます。 それも完璧ではありませんが、修理を続けることができるということです。

これが完全ではなく、フィールドの名前変更が一般的にこの提案で対処されていないのは間違いありません。 埋め込みは基になる名前に敏感であってはならず、「名前NとしてXを埋め込む」ためのある種の構文が必要である可能性があります。 後でフィールドエイリアスを追加する必要がある場合もあります。 どちらも先験的に合理的なアイデアのように思われ、おそらく両方とも別々である必要があり、後の提案は必要性の実際の証拠に基づいて評価されます。 タイプエイリアスが、フィールドエイリアスの欠如が大規模なリファクタリングの次の大きな障害となる点に到達するのに役立つ場合、それは進歩するでしょう！

（/ cc @neildおよび@bcmills）

@atdiar 、はい、

@rsc私が念頭に置いていたのは、a）エイリアスとその定義タイプの両方を同じ構造体に埋め込むことを禁止する（bからのあいまいさを防ぐため）、b）ソースコード内のいずれかの名前でフィールドを参照できるようにする、c）いずれかを選択するまたは生成されたタイプ情報/リフレクションなどのその他（どちらでも構いません）。

これは、私が説明しようとした種類の破損を回避するのに役立つと同時に、選択が必要な場合の明確な選択を行うのに役立つと、私は手を振って主張します。 そして、個人的には、リフレクションに依存するコードを壊さないことよりも、リフレクションに依存するコードを壊さないことに関心があります。

あなたのByteBuffer引数を理解しているかどうかは今のところわかりませんが、私も長い仕事の終わりにいるので、それ以上説明する必要はありません。納得がいかない場合は、最終的に応答します:)

@Merovius単純なルールを試して、より複雑なルールを導入する前に、どこまで到達できるかを確認するのは理にかなっていると思います。 必要に応じて、後で（a）と（b）を追加できます。 （c）は何があっても与えられます。

私は、（b）が特定の状況では良い考えであるかもしれないが、他の状況ではそうではないかもしれないことに同意します。 前述の「1つのパッケージAPIを複数の実装パッケージに構造化する」ユースケースにタイプエイリアスを使用している場合は、エイリアスを埋め込んで他の名前（内部パッケージに含まれている可能性があります）を公開したくない場合があります。それ以外の場合、ほとんどのユーザーはアクセスできません）。 もっと経験を積んでいただければと思います。

@rsc

おそらく、エイリアス可能性に関するパッケージレベルの情報をオブジェクトファイルに追加すると役立つ場合があります。
（goプラグインが適切に機能し続ける必要があるかどうかを考慮に入れながら。）

@Merovius @rsc

a）エイリアスとその定義型の両方を同じ構造体に埋め込むことを禁止する

多くの場合、埋め込みがメソッドセットと相互作用する方法の結果として、これはすでに禁止されていることに注意してください。 （埋め込み型に空でないメソッドが設定されていて、それらのメソッドの1つが呼び出された場合、プログラムはコンパイルに失敗します：https：//play.golang.org/p/XkaB2a0_RK。）

したがって、二重埋め込みを禁止する明示的なルールを追加しても、ごく一部のケースでのみ違いが生じるように思われます。 私には複雑にする価値がないようです。

代わりに代数型として型エイリアスにアプローチし、型のセットへのエイリアスをサポートして、コンパイル時の型チェックと同等の空のインターフェイスをボーナスとして取得してみませんか？

type Stringeroonie = {string,fmt.Stringer}

@ j7b

代わりに代数型として型エイリアスにアプローチし、一連の型へのエイリアスをサポートしてみませんか

エイリアスは、意味的および構造的に元のタイプと同等です。 代数的データ型はそうではありません。一般的な場合、タイプタグ用に追加のストレージが必要です。 （Goインターフェース型はすでにその型情報を持っていますが、構造体や他の非インターフェース型は持っていません。）

@bcmills

これは誤った推論かもしれませんが、タイプTのエイリアスAは、Aをインターフェイス{}として宣言し、タイプAの変数が宣言されているスコープでコンパイラにタイプAの変数を透過的に変換させることと同等であるため、問題に取り組むことができると思いました。 、これはほとんど線形のコンパイル時コストであり、明確であり、 type T =構文を使用して代数を含むコンパイラ管理の疑似型の基礎を作成し、コンパイル時に不変の参照などの型を実装できるようにすることもできます。ユーザーコードに関する限り、インターフェース{}は「内部」にすぎません。

その一連の思考の欠陥はおそらく無知の産物であり、私は概念の実用的な証明を提供する立場にないので、それが不十分であることを受け入れて延期することを嬉しく思います。

@ j7b 1つの段階的な修復問題の解決策があるADTであっても、独自の問題を作成します。 依存関係を壊さずにADTのメンバーを追加または削除することは不可能です。 したがって、本質的には、解決するよりも多くの問題を作成することになります。

interface {}との間で透過的に変換するというあなたの考えは、 []interface{}ような高次の型でも機能しません。 そして最終的には、goの長所の1つを失うことになります。それは、ユーザーがデータレイアウトを制御できるようにし、代わりにすべてをラップするJavaの処理を実行することです。

ADTはここでの解決策ではありません。

@Merovius代数型の構成に名前の変更が含まれている場合（これは同じの合理的な定義と一致します）、それは解決策であり、そのインターフェイス{}はコンパイラが管理する射影と選択の形式のプロキシとして機能できると確信しています。説明されており、データレイアウトがどのように関連しているか、「高次」型をどのように定義しているかはわかりません。型は、宣言できる場合は単なる型であり、[] interface {}は単なる型です。

それはさておき、 type T =は、名前の変更を超えた直感的で便利な方法でオーバーロードされる可能性があることを確信しています。代数型と公的に不変の参照は最も明白なアプリケーションのようです。したがって、仕様にその構文が記載されていることを願っています。コンパイラが管理するメタ型または疑似型を示し、コンパイラが管理する型が役立つ可能性のあるすべての方法と、それらの使用法を最もよく表す構文が考慮されます。 新しい構文は、修飾子として使用するときにグローバルに予約された単語のセットに関係する必要がないため、 type A = alias Typeようなものは明確で拡張可能です。

@ j7b

それはさておき、私はポジティブタイプですT =名前を変更するだけでなく、直感的で便利な方法でオーバーロードされる可能性があります。

私は確かにそうしないことを望みます。 今日、Goは（ほとんど）うまく直交しており、その直交性を維持することは良いことです。

今日、Goで新しい型Tを宣言する方法はtype T def 。ここで、 defは新しい型の定義です。 代数的データ型（別名タグ付き共用体）を実装する場合、型エイリアスの構文ではなく、その構文に従うことを期待します。

私はタイプエイリアスの別の視点（サポート）を投入するのが好きです。これは、リファクタリング以外の代替ユースケースへの洞察を提供する可能性があります。

少し前に戻って、 type T <a type>の形式の通常の古いGo型宣言がなく、型エイリアス宣言type A = <a type>のみがあると仮定しましょう。

（全体像を完成させるために、メソッドが何らかの形で異なる方法で宣言されていると仮定しましょう-レシーバーとして使用される名前付き型への関連付けではなく、できないためです。たとえば、文字通りメソッドを持つクラス型の概念を想像できます。内部であるため、メソッドを宣言するために名前付き型に依存する必要はありません。構造的に同一であるがメソッドが異なる2つの型は、異なる型になります。この思考実験では、詳細は重要ではありません。）

そのような世界では、今書いているのとほぼ同じコードを書くことができると私は主張します。（エイリアス）型名を使用するので、繰り返す必要はありません。型自体は、型でデータを使用することを確認します。 -安全な方法。

言い換えれば、Goがそのように設計されていたとしたら、私たちも概して大丈夫だったでしょう。

さらに、そのような世界では、タイプは構造的に同一であれば（名前に関係なく）同一であるため、リファクタリングで発生する問題はそもそも現れず、必要もありません。言語の変更。

しかし、現在のGoにあるような安全メカニズムはありません。タイプの名前を導入して、これを新しい別のタイプにする必要があることを示すことはできません。 （それでも、それは本質的に安全メカニズムであることを覚えておくことが重要です。）

他のプログラミング言語では、既存の型とは異なる新しい型を作成するという概念は「ブランディング」と呼ばれます。型getはそれに付けられたブランドであり、他のすべての型とは異なります。 たとえば、Modula-3では、それを実現するための特別なキーワードBRANDEDました（たとえば、 TYPE T = BRANDED REF T0はT0への新しい異なる参照を作成します）。 Haskellでは、型の前のnewという単語も同様の効果があります。

代替のGoの世界に戻ると、リファクタリングに問題はないが、コードの安全性を向上させてtype MyBuffer = []byteとtype YourBuffer = []byte表すようにしたいと思うかもしれません。誤って間違ったものを使用しないように、さまざまなタイプがあります。 まさにその目的のために、タイプブランディングの形式を導入することを提案するかもしれません。 たとえば、 type MyBuffer = new []byte 、またはtype MyBuffer = new YourBufferを記述して、MyBufferがYourBufferとは異なるタイプになるようにすることができます。

これは本質的に、私たちが今持っているものの二重の問題です。 Goでは、初日から、名前が付けられるとすぐに「ブランド」タイプを常に使用していました。 言い換えれば、 type T <a type>は事実上type T = new <a type>です。

要約すると、既存のGoでは、名前付きタイプは常に「ブランド化された」タイプであり、タイプの名前だけの概念がありません（現在はタイプエイリアスと呼んでいます）。 他のいくつかの言語では、タイプエイリアスが標準であり、「ブランディング」メカニズムを使用して、明示的に新しい異なるタイプを作成する必要があります。

重要なのは、両方のメカニズムが本質的に有用であり、タイプエイリアスを使用して、最終的に両方をサポートするために回避できるということです。

@griesemerその機能の拡張は、理想的にはリファクタリングをクリーンアップする必要がある最初のエイリアス提案です。 スコープが制限されているため、タイプエイリアスのみが難しいリファクタリングエッジケースを作成するのではないかと心配しています。

どちらの提案でも、説明したように名前はGoの型定義の一部であるため、リンカーからのコラボレーションは必要ないのではないかと疑問に思っています。

私はオブジェクトコードにまったく精通していないので、それは単なるアイデアですが、オブジェクトファイルにカスタムセクションを追加することは可能のようです。 偶然にも、タイプ名とそのエイリアスのリンク時に埋められた、ある種の展開されたリンクリストを保持することが可能であった場合は、それが役立つ可能性があります。 ランタイムには、個別のコンパイルを犠牲にすることなく、必要なすべての情報が含まれます。

エラーメッセージが明確なままになるように、ランタイムは特定のタイプのさまざまなエイリアスを動的に返すことができる必要があるという考えです（エイリアスによって実行中のコードと記述されたコードの間に名前の不一致が生じるため）。

エイリアシングの使用を追跡する代わりに、コンテキストパッケージで行われたように、パッケージ間でオブジェクト定義を「移動」できるように、具体的なバージョン管理ストーリーを大規模に作成することもできます。 しかし、それはまったく別の問題です。

結局のところ、インターフェイスと名前の同等性を型に残しておくことは、依然として良い考えです。
タイプはより多くの制約のあるインターフェースと見なすことができるという事実を考えると、エイリアスの宣言は、スライスのタイプ名文字列のパッケージごとのスライスを保持することによって実装する必要がある/できるようです。

@atdiar 「個別のコンパイル」と言ったときに私が何をするのか

@ j7dは、型システムレベルでは、合計型または任意の種類のサブタイプ（説明の前半で他の人が提案したように）は、特定の種類の使用にのみ役立ちます。 bytes.Bufferをio.Readerのサブタイプと考えることができるのは事実です（「バッファはリーダーです」、またはあなたの例では「文字列はStringeroonieです」）。 これらを使用してより複雑な型を構築すると、問題が発生します。 このコメントの残りの部分では、Goタイプについて説明していますが、言語が実際に実装しているGoではなく、サブタイプレベルでの基本的な関係について説明しています。 ただし、Goは基本的な関係と一致するルールを実装する必要があります。

型構築子（「型を使用する方法」を言うための派手な方法）は、サブタイプの関係を保持する場合は共変であり、関係を反転する場合は反変です。

関数の結果で型を使用することは共変です。 func（）バッファは、func（）リーダーです。これは、バッファを返すことは、リーダーを返したことを意味するためです。 関数の引数で型を使用することは、共変ではありません。 funcにはBufferが必要であり、一部のReaderはBufferではないため、func（Buffer）はfunc（Reader）ではありません。

関数の引数で型を使用することは逆変です。 func（Reader）はfunc（Buffer）です。これは、funcにはReaderのみが必要であり、BufferはReaderであるためです。 関数の結果で型を使用することは、反変ではありません。 func（）リーダーはfunc（）バッファーではありません。これは、funcがリーダーを返し、一部のリーダーがバッファーではないためです。

この2つを組み合わせると、func（Reader）Readerはfunc（Buffer）Bufferではなく、その逆も同様です。引数が機能しないか、結果が機能しないためです。 （これらの線に沿って機能する唯一の組み合わせは、func（Reader）Bufferがfunc（Buffer）Readerであるということです。）

一般に、func（X1）X2がfunc（X3）X4（のサブタイプ）である場合、X3はX1（のサブタイプ）であり、同様にX2はX4（のサブタイプ）である必要があります。 T1とT2を交換可能にするエイリアス使用の場合、T1がT2のサブタイプであり、T2がT1のサブタイプである場合にのみ、func（T1）T1はfunc（T2）T2のサブタイプです。 つまり、基本的に、T1はT2と_同じ_タイプであり、より一般的なタイプではありません。

関数の引数と結果を使用したのは、それが標準的な例（そして良い例）だからですが、複雑な結果を作成する他の方法でも同じことが起こります。 一般に、出力の共分散（func（）T、<-chan T、またはmap [...] Tなど）と入力の共分散（func（T）、chan <-T、またはmap [Tなど）を取得します。 ] ...）および入出力の強制型の同等性（func（T）T、chan T、* T、[10] T、[] T、struct {Field T}、または変数など）タイプTの）。 実際、例からわかるように、Goで最も一般的なケースは入力+出力です。

具体的には、[]バッファは[]リーダーではありません（ファイルを[]リーダーに保存できますが、[]バッファには保存できないため）。また、[]リーダーは[]バッファではありません（[]からフェッチするため）。 [] BufferからフェッチするとBufferを返す必要がありますが、ReaderはFileを返す場合があります。

これらすべてからの結論は、コードがT1またはT2のいずれかを使用できるように一般的なコード修復の問題を解決したい場合、T1をT2のサブタイプのみにする（またはその逆）スキームでは実行できないということです。 それぞれが他のサブタイプである必要があります（つまり、同じタイプである必要があります）。そうでない場合、これらのリストされた使用法の一部は無効になります。

つまり、段階的なコード修復の問題を解決するには、サブタイプ化だけでは不十分です。 これが、タイプエイリアスが同じタイプに新しい名前を導入する理由です。そのため、サブタイプを試行する代わりに、T1 = T2になります。

このコメントは、2週間前のある種の「代替可能なタイプ」の@iandの提案、および基本的にはそれ以降の@griesemerの応答の拡張にも

トップレベルのディスカッションの概要を更新しました。 変更点：

• TODOを削除して、アダプターに関する議論の要約を更新しました。これはフェードアウトしたようです。
• 埋め込みとフィールド名の変更に関する説明の要約を追加しました。
• 「エイリアスのメソッド」の概要を設計の質問リストから独自のセクションに移動し、最近のコメントを含むように拡張しました。
• リフレクションを使用したプログラムへの影響に関する議論の要約を追加しました。
• 個別のコンパイルに関する議論の要約を追加しました。
• さまざまなサブタイピングベースのアプローチの説明の要約を追加しました。

個別のコンパイルに関する@rsc 、私のコメントは、型定義がエイリアスのリストを保持する必要があるか（個別のコンパイル要件のために大規模に扱いにくい）、または各エイリアスが次のエイリアス名のリストを繰り返し作成することを含むかどうかに関連していますインポートグラフ。すべて、タイプ定義で指定された指定された初期タイプ名に関連しています。 （そして、ランタイムがその情報にアクセスできるように、その情報をどこにどのように保持するか）。

@atdiarシステムのどこにもそのようなエイリアス名のリストはありません。 ランタイムはそれにアクセスできません。 エイリアスは実行時に存在しません。

@rscハァッ、ごめんなさい。 私は頭の中で最初のエイリアスの提案に固執していて、funcのエイリアシングについて考えていました（タイプのエイリアシングについて議論している間）。 その場合、コード内の名前と実行時の名前の間に不一致が生じます。
その場合、runtime.Frameの情報をロギングに使用するには、再考が必要になります。
私に構わずに。

@rsc再要約してございます。 埋め込まれたフィールド名はまだ私を苛立たせます。 提案されたすべての回避策は、古い名前を維持するために恒久的な応急修理に依存しています。 このコメントのより大きなポイント、つまりこれはフィールドの名前変更の特殊なケースであり、これも不可能であるということですが、これは確かに別の問題と見なされ（そして解決され）なければならないことを私に確信させます。 段階的な修復のためにフィールドの名前変更をサポートするために、要求/提案/ディスカッションに対して別の問題を開くことは意味がありますか（おそらく同じgoリリースで対処されます）？

@Merovius 、フィールド名の変更のための段階的なコード修復がシーケンスの次の問題のように見えることに同意します。 その議論を始めるために、誰かが実際の例のスイートを集める必要があると思います。それは、それが広範囲にわたる問題であるという証拠を得ると同時に、潜在的な解決策をチェックするためです。 現実的には、同じリリースでそれが起こっているとは思いません。

2週間先から戻ってきました。 議論は収束したようです。 2週間前のディスカッションの更新でさえ、かなりマイナーでした。

私は私たちに提案します：

• 上記の問題の暫定的な解決策として、タイプエイリアスの提案を受け入れます。
  Go 1.9の開始時（2月1日）に実装を試す準備ができている場合。
• dev.typealias devブランチを作成して、CLを今すぐ確認し（1月）、Go1.9の開始時にマスターにマージできるようにします。
• Go 1.9フリーズの開始近くにタイプエイリアスを保持することについて最終決定を下します（Go 1.8サイクルの一般化されたエイリアスに対して行ったように）。

+1

この変更の背後にある議論の歴史に感謝します。 実装されているとしましょう。 間違いなく、それはコア機能ではなく、言語のかなりフリンジな詳細になるでしょう。 そのため、実際の使用頻度に不釣り合いな言語とツールが複雑になります。 また、言語が誤って悪用される可能性のある表面積が増えます。 そのため、慎重すぎるのは良いことであり、これまでにたくさんの議論があったことをうれしく思います。

@Merovius ：私の投稿を編集してすみません！ 誰も読んでいないと思った。 最初にこのコメントで、 gorenameツールのようなツールがすでに存在する場合、この言語の変更が必要であることに懐疑的な見方を示しました。

@ jcao219これは以前に議論されましたが、驚くべきことに、私はこれをここですぐに見つけることができないようです。 一般的なエイリアス＃16339の元のスレッドと、関連するgolang-nutsスレッドで詳細に説明されています。 つまり、この種のツールは、修復コミットを準備する方法のみを扱い、破損を防ぐために変更を順序付ける方法は扱いません。 変更がツールによって行われたか人間によって行われたかにかかわらず、現在、コードを壊さないコミットのシーケンスはありません（この問題の元のコメントと関連するドキュメントは、このステートメントをより正当化します-深さ）。

より自動化されたツール（たとえば、goツールなどに統合されている）の場合、元のコメントは、「これは、言語の変更ではなく、ツールまたはコンパイラのみの変更である可能性がありますか？」という見出しの下でこれに対処します。

結論として、変更が実装されたとしましょう。 間違いなく、それはコア機能ではなく、言語のかなりフリンジな詳細になるでしょう。

疑問を表明したいと思います。 :)私はこれを当然の結論とは考えていません。

@Merovius

疑問を表明したいと思います。 :)私はこれを当然の結論とは考えていません。

この機能を使用するのは、主に、多くの依存クライアントを持つ重要なGoパッケージのメンテナーになるということだと思います。 言い換えれば、それはすでにGoの専門家である人々に利益をもたらします。 同時に、新しいGoプログラマーがコードを読みにくくする魅力的な方法を提供します。 例外は、長い名前の名前を変更するユースケースですが、通常、自然なGoタイプ名は長すぎたり複雑すぎたりすることはありません。

ドットインポート機能の場合と同様に、チュートリアルとドキュメントでは、この機能についての言及に使用ガイドラインの説明を添付することをお勧めします。

たとえば、私が使用していたと言う「github.com/gonum/graph/simple".DirectedGraphを、そして私はとの別名をしたかったのdigraph入力を避けるためにsimple.DirectedGraphそれは良いでしょう、使用事例？ または、この種の名前変更は、protobufなどによって生成された不当に長い名前に制限する必要がありますか？

@ jcao219 、このページの上部にあるディスカッションの要約があなたの質問に答えます。 特に、次のセクションを参照してください。

• これは、言語の変更ではなく、ツールまたはコンパイラのみの変更である可能性がありますか？
• エイリアスには他にどのような用途がありますか？
• 制限事項（そのセクションから始まる一般的な注意事項）

Goの専門家と新しいGoプログラマーについてのより一般的なポイントとして、Goの明確な目標は、大規模なコードベースでのプログラミングを容易にすることです。 あなたが専門家であるかどうかは、あなたが作業しているコードベースのサイズとは多少関係ありません（たぶん、あなたは他の誰かが始めた新しいプロジェクトで始めたばかりです。あなたはまだこの種の仕事をする必要があるかもしれません。）

OK、ここでの全会一致/静寂に基づいて、（先週https://github.com/golang/go/issues/18130#issuecomment-268614964で提案したように）この提案を承認済みとしてマークし、dev.typealiasブランチを作成します。

優れた要約には、「タイプエイリアスの提案で対処する必要がある他の問題は何ですか？」というセクションがあります。 提案が承認されたと宣言された後、これらの問題に対処するための計画は何ですか？

CLhttps ： //golang.org/cl/34986はこの問題について言及しています。

CLhttps ： //golang.org/cl/34987はこの問題について言及しています。

CL https://golang.org/cl/34988は、この問題について言及しています。

@ulikunitzが問題を再確認します（設計ドキュメントからのこれらの引用はすべて、「タイプT1 = T2」を想定しています）：

1. godocでの処理。 設計ドキュメントでは、godocへの最小限の変更を指定しています。 それが入ると、追加のサポートが必要かどうかを確認できます。 たぶん、しかしそうではないかもしれません。
2. エイリアスで指定された型にメソッドを定義できますか？ はい。 デザインドキュメント：「T1はT2を記述する別の方法であるため、独自のメソッド宣言のセットはありません。代わりに、T1のメソッドセットはT2のメソッドセットと同じです。少なくとも最初の試行では、メソッド宣言に対する制限はありません。同じ宣言でT2を使用する場合、レシーバータイプとしてT1を使用することは有効です。」
3. エイリアスからエイリアスへのエイリアスが許可されている場合、エイリアスサイクルをどのように処理しますか？ サイクルはありません。 設計ドキュメント：「型エイリアス宣言では、型宣言とは対照的に、T2は直接的または間接的にT1を参照してはなりません。」
4. エイリアスはエクスポートされていない識別子をエクスポートできる必要がありますか？ はい。 デザインドキュメント：「T2の形式に制限はありません。他のパッケージからインポートされたタイプを含むがこれに限定されない、任意のタイプにすることができます。」
5. エイリアスを埋め込むとどうなりますか（埋め込みフィールドにどのようにアクセスしますか）？ 名前はエイリアス（プログラムで表示される名前）から取得されます。 デザインドキュメント： https ：//golang.org/design/18130-type-alias#effect-on-embedding。
6. ビルドされたプログラムでエイリアスをシンボルとして使用できますか？ いいえ。設計ドキュメント：「タイプエイリアスは実行時にほとんど表示されません。」 （これから回答が続きますが、明示的には呼び出されません。）
7. Ldflags文字列インジェクション：エイリアスを参照するとどうなりますか？ varエイリアスがないため、これは発生しません。

CL https://golang.org/cl/35091は、この問題について言及しています。

CLhttps ： //golang.org/cl/35092はこの問題について言及しています。

CL https://golang.org/cl/35093は、この問題について言及しています。

@rsc説明に感謝します。

仮定しましょう：

package a

import "b"

type T1 = b.T2

私が理解している限り、T1はb.T2と本質的に同一であり、したがって非ローカルタイプであり、新しいメソッドを定義することはできません。 ただし、識別子T1はパッケージaで再エクスポートされます。 これは正しい解釈ですか？

正しい@ulikunitz

T1は、b.T2とまったく同じタイプを示します。 それは単に別の名前です。 何かがエクスポートされるかどうかは、その名前だけに基づいています（それが示すタイプとは関係ありません）。

@griesemerの応答を明示的にするには：はい、T1はパッケージaからエクスポートされます（t1ではなくT1であるため）。

CL https://golang.org/cl/35099は、この問題について言及しています。

CL https://golang.org/cl/35100は、この問題について言及しています。

CL https://golang.org/cl/35101は、この問題について言及しています。

CLhttps ： //golang.org/cl/35102はこの問題について言及しています。

CLhttps ： //golang.org/cl/35104はこの問題について言及しています。

CLhttps ： //golang.org/cl/35106はこの問題について言及しています。

CLhttps ： //golang.org/cl/35108はこの問題について言及しています。

CLhttps ： //golang.org/cl/35120はこの問題について言及しています。

CLhttps ： //golang.org/cl/35121はこの問題について言及しています。

CLhttps ： //golang.org/cl/35129はこの問題について言及しています。

CL https://golang.org/cl/35191は、この問題について言及しています。

CL https://golang.org/cl/35233は、この問題について言及しています。

CLhttps ： //golang.org/cl/35268はこの問題について言及しています。

CLhttps ： //golang.org/cl/35269はこの問題について言及しています。

CL https://golang.org/cl/35670は、この問題について言及しています。

CLhttps ： //golang.org/cl/35671はこの問題について言及しています。

CLhttps ： //golang.org/cl/35575はこの問題について言及しています。

CLhttps ： //golang.org/cl/35732はこの問題について言及しています。

CL https://golang.org/cl/35733は、この問題について言及しています。

CLhttps ： //golang.org/cl/35831はこの問題について言及しています。

CLhttps ： //golang.org/cl/36014はこの問題について言及しています。

これは、Go 1.9のオープンに先立って、現在マスターになっています。 マスターで同期して、試してみてください。 ありがとう。

＃18893からリダイレクト

package main

import (
        "fmt"
        "q"
)

func main() {
        var a q.A
        var b q.B // i'm a named unnamed type !!!

        fmt.Printf("%T\t%T\n", a, b)
}

何を見たいと思いましたか？

deadwood(~/src) % go run main.go
q.A     q.B

代わりに何を見ましたか？

deadwood(~/src) % go run main.go
q.A     []int

議論

名前のないタイプにエイリアスを適用しないでください。 それらは、ある名前のないタイプから別のタイプに移動する際の「コード修復」の話ではありません。 名前のないタイプでエイリアスを許可すると、Goを単に名前の付いたタイプと名前のないタイプとして教えることができなくなります。 代わりに私は言わなければなりません

ああ、それがエイリアスでない限り、その場合、別のパッケージからインポートする場合でも、名前のないタイプである可能性があることを覚えておく必要があります。

さらに悪いことに、それは人々が次のような読みやすさのアンチパターンを公布することを可能にします

type Any = interface{}

名前のないタイプにエイリアスを付けないでください。

@davecheney

名前のないタイプから別のタイプに移動する場合、「コード修復」の話はありません。

違います。 メソッドパラメータの型を名前付き型から名前なし型に、またはその逆に変更したい場合はどうなりますか？ ステップ1はエイリアスを追加することです。 ステップ2は、そのメソッドを実装するタイプを更新して、新しいタイプを使用することです。 手順3は、エイリアスを削除することです。

（メソッドの名前を2回変更することで、今日それを実行できるのは事実です。名前の変更を2回行うのは、せいぜい面倒です。）

さらに悪いことに、それは人々が次のような読みやすさのアンチパターンを公布することを可能にします
type Any = interface{}

今日、人々はすでにtype Any interface{}書くことができます。 この場合、エイリアスはどのような追加の害をもたらしますか？

今日、人々はすでにタイプAny interface {}を書くことができます。 この場合、エイリアスはどのような追加の害をもたらしますか？

それがまさにそれであるため、私はそれをアンチパターンと呼びました。 type Any interface{} 、コードを書く人は少し短いものをタイプするので、それは彼らにとってもう少し意味があります。

反対に、Goコードの読み取りに経験があり、鏡の中の顔と同じくらい本能的にinterface{}を認識する読者の_すべて_は、 Anyすべてのバリエーションを学習して再学習する必要があります。 、 Object 、 T 、およびパッケージごとにtype Any interface{} 、 type Any map[interface{}]interface{} 、 type Any struct{}などにマップします。

確かに、一般的なGoイディオムのパッケージ固有の名前が読みやすさの正味のネガティブであることに同意しますか？

確かに、一般的なGoイディオムのパッケージ固有の名前が読みやすさの正味のネガティブであることに同意しますか？

私は同意しますが、問題の例（私が遭遇したその反パターンの最も一般的な発生）はエイリアスなしで実行できるため、その例がタイプエイリアスの提案にどのように関連しているかわかりません。

アンチパターンが型エイリアスなしで可能であるという事実は、名前のない型へのエイリアスが存在できるかどうかに関係なく、それを回避するようにGoプログラマーをすでに教育する必要があることを意味します。

実際、型エイリアスを使用すると、アンチパターンがすでに存在するコードベースからそのアンチパターンを_段階的に削除_できます。

検討：

package antipattern

type Any interface{}  // not an alias

type Widget interface{
  Frozzle(Any) error
}

func Bozzle(w Widget) error {
  …
}

今日、 antipattern.Bozzleユーザーは、 Widget実装でantipattern.Anyを使用してスタックし、段階的な修復でantipattern.Anyを削除する方法はありません。 ただし、タイプエイリアスを使用すると、 antipatternパッケージの所有者は次のように再定義できます。

// Any is deprecated; please use interface{} directly.
type Any = interface{}

これで、発信者はAnyからinterface{}徐々に移行できるようになり、 antipatternメンテナが最終的にそれを削除できるようになります。

私のポイントは、名前のないタイプをエイリアスする理由がないので、
このオプションを禁止すると、
練習。

逆に、名前のないタイプのエイリアシングを許可すると、1つではなく2つが有効になります
このアンチパターンの形式。

木、2017年2月2日には、16時34ブライアンC.ミルズ[email protected]は書きました：

確かに、一般的なGoイディオムのパッケージ固有の名前は次のとおりです。
読みやすさの正味のネガティブ？

私は同意しますが、問題の例以来（はるかに最も一般的です
私が遭遇したその反パターンの発生）はなしで行うことができます
エイリアス、その例が提案にどのように関連しているかわかりません
タイプエイリアス。

タイプエイリアスなしでアンチパターンが可能であるという事実は、
それを回避するために、Goプログラマーを教育する必要があります。
名前のないタイプのエイリアスが存在する可能性があります。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/18130#issuecomment-276872714 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAAcA6BGrFjjTi7eW1BPp7o81XIekbGXks5rYWr-gaJpZM4LBBEL
。

@davecheney任意の型のリテラルに名前を付けることができることは有害であるという証拠はまだないと思います。 これも予期しない「驚き」の機能ではありません。設計ドキュメントで詳細に説明されて

反例として、APIがクライアントを特定の型に制限したくないという理由だけで型リテラルを使用するパブリックAPIがあります（たとえば、https：//golang.org/pkg/go/types/#Infoを参照してください）。 ）。 その明示的な型リテラルを持つことは、有用なドキュメントかもしれません。 しかし同時に、同じタイプのリテラルをあちこちで繰り返さなければならないのは非常に面倒な場合があります。 実際、読みやすさの妨げになります。 map[int]struct{}に縛られることなくIntSetではなく、 IntSet定義だけが私の頭の中でプラスになります。 それがtype IntSet = map[int]struct{}が正確に正しいところです。

最後に、見逃した場合に備えて、 https： //github.com/golang/go/issues/18130#issuecomment-268411811を参照して=を使用した無制限の型宣言は、実際には「基本的な」型宣言であり、ついにGoに組み込まれたことをうれしく思います。

おそらくtype intSet = map[int]struct{} （エクスポートされない）が名前のない型エイリアスを使用するためのより良い方法ですが、これは機能を制限するのではなく、CodeReviewCommentsのドメインと推奨されるプログラミング手法のように聞こえます。

とは言うものの、 %Tは、型システムをデバッグまたは探索するときに型を確認するための便利なツールです。 エイリアスを含む同様の形式の動詞があるべきかどうか疑問に思いますか？ @davecheneyの例ではq.B = []int 。

@nathanyその動詞をどのように実装しますか？ エイリアス情報は実行時に存在しません。 （ reflectパッケージに関する限り、エイリアスはエイリアスの対象となるものと_同じタイプ_です。）

@bcmillsそうかもしれないと思った...😞

エイリアスの操作に役立つ静的分析ツールとエディタープラグインがまだ残っていると思いますので、問題ありません。

2017年2月2日17:01、「NathanYoungman」 [email protected]は次のように書いています。

とは言うものの、％Tは、デバッグまたは探索するときに型を確認するための便利なツールです。
型システム。 似たようなフォーマットの動詞があるべきかしら
エイリアスが含まれていますか？ qB = [] int in @davecheney
https://github.com/davecheneyの例。

より良い解決策は、これに答えるために教祖にクエリモードを追加することだと思います
質問：

これは、GOPATH全体（または特定のパッケージ）で宣言されたエイリアスです。
コマンドラインでこの特定のタイプ？

名前のないタイプのエイリアシングの乱用については心配していませんが、可能性があります
同じ名前のないタイプにエイリアスを複製しました。

@davecheney上部のディスカッションサマリーの「制限」セクションにあなたの提案を追加しました。 すべての制限と同様に、私たちの一般的な見解は、制限は複雑さを増すというものであり（上記の注を参照）、制限を導入するためには、広範囲にわたる危害の実際の証拠を確認する必要があります。 Goの教え方を変えるだけでは不十分です。言語を変更するには、Goの教え方を変える必要があります。

デザインドキュメントとメーリングリストに記載されているように、説明を簡単にするために、より適切な用語に取り組んでいます。

@minuxは、 @ bcmillsが指摘したように、実行時にエイリアス情報が存在しません（完全に設計の基本です）。 「エイリアスを含む％T」を実装する方法はありません。

2017年2月2日午後8時33分、「RussCox」 [email protected]は次のように書いています。

@minux https://github.com/minux、@bcmillsなど
https://github.com/bcmillsが指摘しましたが、エイリアス情報は存在しません
実行時（完全に設計の基本）。 する方法はありません
「エイリアスを含む％T」を実装します。

Goの第一人者（https://golang.org/x/tools/cmd/guru）クエリモードを提案しています
静的コード分析に基づく逆エイリアスマッピング用。 それ
実行時にエイリアス情報が利用可能かどうかは関係ありません。

@minux 、なるほど、あなたはメールで返信していて、Githubは引用されたテキストをあなたが自分で書いたテキストのように見せます。 ネイサン・ヤングマンから引用したテキストに、あなたのものだと思って返信していました。 混乱させて申し訳ありません。

用語と教育に関しては、 @ griesemerが投稿したブランドタイプの背景が非常に有益であることがわかりました。 それをありがとう。

型と型変換を説明するとき、赤ちゃんのホリネズミは最初、おそらく他の言語に精通しているために、私が型エイリアスについて話していると思います。

最終的な用語が何であれ、名前付き（ブランド）タイプの前にタイプエイリアスを導入することを想像できます。特に、新しい名前付きタイプの宣言は、本やカリキュラムにbyteとruneを導入した後に行われる可能性が高いためです。 ただし、アンチパターンを奨励しないという@davecheneyの懸念に留意したいと思います。

type intSet map[int]struct{}場合、 map[int]struct{}は_underlying_タイプであると言います。 type intSet = map[int]struct{}どちらかの側を何と呼びますか？ エイリアスとエイリアスタイプ？

%Tについては、 byteとruneがuint8とint32になることを説明する必要があるので、これは違います。違う。

どちらかといえば、タイプエイリアスによってbyteとrune説明が簡単になると思います。 IMOの課題は、名前付きタイプとタイプエイリアスをいつ使用するかを知り、それを伝達できるようにすることです。

@nathany最初に「エイリアスタイプ」を導入することは理に

従来の（エイリアス以外の）型宣言は、より多くの作業を行います。左側の識別子をバインドする前に、まず右側の型から新しい型を作成します。 したがって、右側の識別子と型は同じではありません（同じ基になる型のみを共有します）。 これは明らかにより複雑な概念です。

どのタイプにも名前を付けることができるようになったため、これらの新しく作成されたタイプには新しい用語が必要です。 そして、それらを参照するスペックルール（タイプID、割り当て可能性、レシーバーベースタイプ）があるため、それらを参照できる必要があります。

これを説明する別の方法があります。これは、教育環境で役立つ場合があります。タイプは、色付きまたは色なしのいずれかです。 事前に宣言されたすべての型、およびすべての型リテラルは色付けされていません。 新しい色付きの型を作成する唯一の方法は、従来の（エイリアス以外の）型宣言を使用することです。この宣言では、最初に右側の型をまったく新しい、これまで使用されたことのない色でペイントします（古い色を取り除きます。左側の識別子をバインドする前に、もしあれば、完全に処理中です。 繰り返しますが、識別子と（暗黙的および目に見えない形で作成された）色付きのタイプは同じですが、右側に記載されている（異なる色または色なしの）タイプとは異なります。

このアナロジーを使用して、他のさまざまな既存のルールを再定式化することもできます。

• 色付きの型は、他の型とは常に異なります（各型宣言は、まったく新しい、これまでに使用されたことのない色を使用するため）。
• メソッドは、色付きのレシーバーベースタイプにのみ関連付けることができます。
• タイプの基礎となるタイプは、そのタイプがすべての色を取り除いたものです。
  NS。

定数名をエイリアスとは呼ばず、定数値をエイリアス定数と呼びます

良い点👍

色付きと色なしのアナロジーが理解しやすいかどうかはわかりませんが、概念を説明する方法が複数あることを示しています。

伝統的な名前付き/ブランド/色付きのタイプは確かにもっと説明が必要です。 特に、既存の名前付き型を使用して名前付き型を宣言できる場合。 覚えておくべきかなり微妙な違いがあります。

type intSet map[int]struct{} // a new type with an underlying type map[int]struct{}

type myIntSet intSet // a new type with an underlying type map[int]struct{}

type otherIntSet = intSet // just another name (alias) for intSet, add methods to intSet (only in the same package)

type literalIntSet = map[int]struct{} // just another name for map[int]struct{}, no adding methods

しかし、それは乗り越えられないわけではありません。 これがGo1.9にあると仮定すると、いくつかのGo本の第2版が表示されると思います。 😉

受け入れられている用語については、定期的にGo仕様を参照しているので、最終的にどの用語が選択されるのか非常に興味があります。

どのタイプにも名前を付けることができるようになったため、これらの新しく作成されたタイプには新しい用語が必要です。

いくつかのアイデア：

• 「区別される」または「区別される」（のように、他のタイプと区別することができます）
• 「ユニーク」（他のすべてのタイプとは異なるタイプです）
• 「具体的」（のように、それはランタイムに存在するエンティティです）
• 「識別可能」（のように、タイプにはIDがあります）

@bcmills私たちは、区別された、ユニークな、区別された、ブランド化された、色付けされた、定義された、非エイリアスなどのタイプについて考えてきました。 「具象」は、インターフェースにも色を付けることができ、インターフェースは抽象型の化身であるため、誤解を招く恐れがあります。 「struct {int}」は明示的に（エイリアス以外の）名前が付けられた型と同じように識別可能であるため、「識別可能」も誤解を招くように思われます。

私は反対することをお勧めします：

• 「色付き」（プログラミング以外のコンテキストでは、「色付きのタイプ」というフレーズは人種的偏見の強い意味合いを持っています）
• 「非エイリアス」（エイリアスのターゲットが以前は「名前付き型」と呼ばれていたものである場合とそうでない場合があるため、混乱を招きます）
• 「定義済み」（エイリアスも定義されています。エイリアスとして定義されているだけです）

「ブランド」は機能する可能性があります。「牛のようなタイプ」という意味合いがありますが、本質的に悪いとは思いません。

ユニークで独特なものは、これまでのところ際立った選択肢のようです。

それらは、多くの追加のコンテキストや知識がなくても、シンプルで理解しやすいものです。 私がその区別を知らなかったならば、私は少なくともそれらが何を意味するかについての一般的な感覚を持っていると思います。 他の選択肢については言えません。

用語を学んだらそれは重要ではありませんが、意味のある名前は区別を内面化するための不必要な障壁を回避します。

これは、自転車小屋の議論の定義です。 ロバートはhttps://go-review.googlesource.com/#/c/36213/に保留中のCLを持ってい

CLhttps ： //golang.org/cl/36213はこの問題について言及しています。

go fixもう一度取り上げたいと思います。

私がエイリアスを「削除」することを提案していないことを明確にするために。 多分それは他の仕事に有用で適切なものであり、それは別の話です。

タイトルが移動タイプに関するものであることは、非常に重要なIMOです。 私はこの問題を当惑させたくありません。 私たちの目的は、プロジェクトの一種のインターフェース変更に対処することです。 インターフェイスの変更に関しては、すべてのユーザーがこれら2つのインターフェイス（古いものと新しいもの）を最終的に同じものとして使用することを望んでいるわけではありません。そのため、「段階的なコード修復」と言います。 ユーザーが古いものの使用法を削除/変更することを願っています。

@ tux21bが提案したアイデアのように、私は今でもツールをコードを修復するための最良の方法だと考えています。 例えば：

$ cat "$GOROOT"/RENAME
# This file could be used for `go fix`
[package]
x/net/context=context
[type]
io.ByteBuffer=bytes.Buffer

$ go fix -rename "$GOROOT"/RENAME [packages]
# -- or --
# use a standard libraries rename table as default
$ go fix -rename [packages]
# -- or --
# include this fix as default
$ go fix [packages]

@rscがここでしかし、このワークフローでは正しくないと思います。古いパッケージ（依存関係など）がパッケージの非推奨の名前/パス（ x/net/contextなど）を使用している場合は、最初にコードを修正できます、ドキュメントがコードを新しいバージョンに移行する方法を説明しているように、テキスト形式の構成可能なテーブルを介してハードコーディングはしていません。 そうすれば、新しいバージョンのGoと同じように、いつでも好きなときに任意のツールを使用できます。 副作用があります：それはコードを変更します。

@LionNatsu 、あなたは正しいと思いますが、それは別の問題だと思います。APIの変更に応じて機械的な方法でコードを更新する方法を潜在的なクライアントに説明するために、パッケージの規則を採用する必要がありますか？ おそらく、しかし、それらの規則が何であるかを理解する必要があります。 この会話を振り返って、このトピックについて別の問題を開くことができますか？ ありがとう。

CL https://golang.org/cl/36691は、この問題について言及しています。

この提案をヒントにすると、次のパッケージを作成できます。

package safe

import "unsafe"

type Pointer = unsafe.Pointer

これにより、プログラムはunsafe直接インポートせずにunsafe.Pointer値を作成できます。

package main

import "safe"

func main() {
    x := []int{4, 9}
    y := *(*int)(safe.Pointer(uintptr(safe.Pointer(&x[0])) + 8))
    println(y)
}

元のエイリアス宣言の設計ドキュメントでは、これを明示的にサポートされていると呼びかけています。 この新しいタイプのエイリアス提案では明示的ではありませんが、機能します。

エイリアス宣言の問題について、これの理由は次のとおりです。_ "unsafe.Pointerのエイリアスを許可する理由は、unsafe.Pointerを持つ型を基になる型として定義することがすでに可能であるためです。" _ https：//github.com/ golang / go / issues / 16339＃issuecomment -232435361

それは本当ですが、 unsafe.Pointerエイリアスを許可すると、何か新しいことが導入されると思います。プログラムは、安全でないものを明示的にインポートすることなく、 unsafe.Pointer値を作成できるようになりました。

この提案の前に上記のプログラムを作成するには、safe.Pointerキャストを安全でないものをインポートするパッケージに移動する必要があります。 これにより、プログラムの安全でない使用を監査することが少し難しくなる可能性があります。

@crawshaw 、これまでにこれをやったことがなかったのですか？

package safe

import (
  "reflect"
  "unsafe"
)

func Pointer(p interface {}) unsafe.Pointer {
  switch v := reflect.ValueOf(p); v.Kind() {
  case reflect.Uintptr:
    return unsafe.Pointer(uintptr(v.Uint()))
  default:
    return unsafe.Pointer(v.Pointer())
  }
}

これにより、パッケージmain同じインポートがない状態で、まったく同じプログラムをコンパイルできるようになると思います。

（必ずしも有効なプログラムであるとは限りません。 uintptrからPointerへの変換には関数呼び出しが含まれているため、 " unsafeパッケージの制約を満たしていません。両方の変換は同じ式に含まれている必要があり、それらの間に算術演算が介在しているだけです。」ただし、 mainからunsafeをインポートしなくても、同等の有効なプログラムを作成できると思います。 reflect.SliceHeaderようなものの使用。）

非表示の安全でないタイプをエクスポートすることは、監査に追加するもう1つのルールのようです。

はい、私は直接エイリアシングが安全ではないことを指摘したいと思いました。ポインターはコードの監査を難しくするので、誰もそうしないことを願っています。

@crawshaw私のコメントによると、これはタイプエイリアシングが発生する前にも当てはまりました。 以下が有効です。

package a

import "unsafe"

type P unsafe.Pointer

package main

import "./a"
import "fmt"

var x uint64 = 0xfedcba9876543210
var h = *(*uint32)(a.P(uintptr(a.P(&x)) + 4))

func main() {
    fmt.Printf("%x\n", h)
}

つまり、パッケージmainでは、 unsafeパッケージがなく、 a.Pがエイリアスではない場合でも、 a.Pを使用して安全でない演算を実行できます。 これは常に可能でした。

あなたが言及している他の何かがありますか？

私の間違い。 私はそれがうまくいかなかったと思いました。 （unsafe.Pointerに適用される特別なルールは、そこから定義された新しい型には伝播しないという印象を受けました。）

仕様は実際にはこれについて明確ではありません。 go / typesの実装を見ると、私の最初の実装では、基礎となるタイプがunsafe.Pointerであったタイプだけでなく、正確にunsafe.Pointer必要であることがわかりました。 go / typesをgc準拠に変更したときの＃6326を見つけました。

おそらく、通常の型定義ではこれを禁止し、 unsafe.Pointerエイリアスも禁止する必要があります。 私はそれを許可する正当な理由を見ることができず、安全でないコードのためにunsafeをインポートしなければならないという明示性を危うくします。

https://github.com/golang/go/issues/19306を作成しました

これが起こりました。 ここには何も残っていないと思います。