Go Wiki：Go 2 泛型回饋意見

此頁面旨在收集和整理有關 Go 2 合約 (泛型) 草案設計的回饋意見。

語法的原型實作可以在 https://go.dev.org.tw/cl/149638 中找到，它可以修補在 Go 儲存庫的提示上。

請在你的部落格、Medium、GitHub Gists、郵寄清單、Google Docs 等地方張貼回饋。然後請在此處連結它。

隨著回饋數量增加，請隨時根據具體的回饋類型整理或重新整理此頁面。

支持

Roger Peppe，“Go 合約使用案例：通用 mgo”，2018 年 9 月
Richard Fliam，“Go2 泛型讓你建構自然數”，2018 年 8 月
Roger Peppe，“執行時期的 Go 泛型”，第 1 部分，第 2 部分，2018 年 9 月

補充（支持修改）

Matt McCullough，“邁向清晰：Go 中合約的語法變更”和“Go 合約的尖括號分隔符”，2020 年 5 月
Gert Cuykens，“通用語法形式與一般 Go 程式碼的完全分隔”，2020 年 1 月
Court Fowler，“一位懶惰程式設計師對更新設計的想法”，2019 年 9 月
Andrew Phillips，“範例類型作為合約”，2019 年 8 月
Alexey Nezhdanov，“語法簡化提案”，2019 年 8 月
Bryan Ford，“只有類型參數對 Go 2 泛型來說夠通用嗎？”，2019 年 7 月
Tom Levy，“Go 2 泛型回饋”，2019 年 6 月
Ole Bulbuk，〈在 Go 社群變遷的背景下，為何 Go 合約是個壞主意〉，2019 年 4 月
Tony Mottaz，〈Go 泛型類型和導入注入〉，2019 年 3 月
Gustavo Bittencourt，〈僅針對泛型類型的合約〉，2019 年 3 月
David Heuschmann，〈使用括號表示類型引數清單的問題〉，2019 年 2 月
Gustavo Bittencourt，〈具有方法的合約〉，2019 年 2 月
Chris Siebenmann，〈Go 2 泛型：合約太聰明了〉，2018 年 11 月
Chris Siebenmann，〈Go 2 泛型：讓合約更易於閱讀的方法〉，2018 年 11 月
Chris Siebenmann，〈Go 2 泛型：介面不是類型限制的正確模型〉，2018 年 11 月
alanfo，〈根據收到的回饋，對 Go 泛型設計草案的建議變更〉，2018 年 10 月
Andy Balholm，〈列舉和結構化合約〉，2018 年 10 月
Burak Serdar，〈類型是合約〉，2018 年 10 月
Patrick Smith，〈適用於內建和使用者定義類型參數的 Go 泛型〉，2018 年 9 月
Jacob Carlborg，〈Go 2 草案 D 修正〉，2018 年 9 月
alanfo，〈簡化的泛型限制系統〉，2018 年 9 月
Paul Borman，〈簡化語法〉，2018 年 9 月
mrwhythat，〈Go 2 泛型草案備忘錄〉，2018 年 9 月
Roger Peppe，〈運算子重載〉，2018 年 9 月
Peter McKenzie，〈替代泛型語法〉，2018 年 9 月
Ted Singer，〈語法的設計目標是幫助人類閱讀〉，2018 年 9 月
alanfo，〈建議修改 Go 2 泛型草案設計〉，2018 年 9 月
Dean Bassett，〈如果我們要使用合約，請允許在字串上使用一元 +，2018 年 9 月
Kevin Gillette，〈關於 Go 2 泛型草案〉，2018 年 9 月
jimmy frasche，〈不應允許嵌入類型參數〉，2018 年 8 月
Javier Zunzunegui，〈編譯泛型〉，2018 年 8 月
Liam Breck，〈請不要破壞函式簽章〉，2018 年 8 月
DeedleFake，〈Go 2 設計草案的回饋〉，2018 年 8 月
Roberto (empijei) Clapis，〈難以閱讀的語法〉，2018 年 8 月
Dominik Honnef，〈我對 Go 泛型草案的想法〉，2018 年 8 月

反建議

dotaheor，「將泛型宣告為具有泛型參數的迷你套件」，2020 年 8 月
Beoran，「衛生巨集」，2019 年 6 月
Randy O’Reilly，「泛型原生類型」，2019 年 6 月
Michal Štrba，「放棄限制類型」，2019 年 5 月
Eric Miller，「使用常數結構欄位進行簡單泛型」，2019 年 3 月
dotaheor，「統一 Go 內建和自訂泛型的解決方案」，2019 年 2 月
Quentin Quaadgras，無語法變更，1 個新類型，1 個新內建，2018 年 12 月
Andy Balholm，「合約和適配器」，2018 年 11 月
Dean Bassett，「合約嵌入」，2018 年 10 月
Patrick Smith，「使用適配器的 Go 泛型」，2018 年 10 月
Ian Denhardt，「Go 泛型：具體提案重新使用介面而非合約。」，2018 年 10 月
Arendtio「受介面啟發的 Go 泛型」，2018 年 9 月
Scott Cotton，「統一合約和介面的提案草案修改」(diff），2018 年 9 月
ohir，「CGG，工匠 Go 泛型」，2018 年 9 月
~~Dean Bassett，「使用介面而非合約」，2018 年 9 月~~
我提出了一個第二個建議（「合約嵌入」），列在下方，它解決了這個建議的問題
dotaheor，「將合約和程式碼結合在一起，並將泛型視為具有多個輸出的編譯時期呼叫」，2018 年 9 月。（不時更新）
Aleksei Pavliukov，「延伸型別和函式關鍵字」，2018 年 9 月
Han Tuo，「泛型作為一種型別 – 型別 T 泛型 {int, float64}」，2018 年 9 月
Nate Finch，「Go2 合約走得太遠」，2018 年 9 月
Roger Peppe，「Go 合約作為型別結構」，2018 年 9 月
Axel Wagner，「廢除合約」，2018 年 9 月
Matt Sherman「泛型作為內建型別類別」，2018 年 9 月
Roger Peppe，「已修改的泛型建議」，2018 年 9 月
Steven Blenkinsop，「回應 Go2 合約草案設計 – 輔助型別」，2018 年 9 月
Dave Cheney，「也許將泛型加入 Go 畢竟是關於語法」，2018 年 9 月
Christian Surlykke，「Go 泛型的限制，2018 年 9 月」
go-nuts 上的一些 Gophers，「統一介面和合約」，2018 年 8 月
Roger Peppe，「Go 泛型回饋，2018 年 8 月
Ruan Kunliang，「套件層級泛型」，2018 年 8 月
艾蜜莉·梅爾，「具體說明泛型」，2018 年 8 月

反對

東京 Gophers，「Go 2 草案設計回饋活動評論」，2018 年 10 月

傑森·莫伊倫，「Go2 泛型草案筆記」，2018 年 9 月
柴川芳樹，「泛型/合約提案回饋，2018 年 9 月」

新增您的回饋

請將所有條目格式化如下。

您的姓名，「標題」，年月

為了更輕鬆地查看新回饋。請建立一個 Gist。並協助將清單按反向時間順序排序，方法是在類別清單的頂端新增您的新條目。

快速評論

切斯特·高爾德：此提案唯一的問題在於，明確的合約似乎只會讓程式碼更冗長，這與簡潔可讀程式碼的目標相違背。與其撰寫明確的合約，不如將我們撰寫的實際程式碼用作一種「隱含合約」，這樣會更簡單優雅。此處顯示一個範例。我承認這已於此處處理，但我不同意明確的合約是解決問題的方法。在我看來，合約非常接近介面提供的內容，因此應擴充介面的行為，以允許更接近合約的行為，而不是為語言新增一個全新的陳述類型。
Izaak Weiss：許多討論都特別著重在如何實作合約，或類似的事情。然而，大多數的「有用範例」不需要合約；它們只需要參數多型。撰寫類型安全的 Merge 或 SortSlice 在沒有合約的情況下也是可行的。而對於較簡單的合約，我們可以使用高階函式來實作它們。通用雜湊表可以參數化為具有 Hash 方法的類型，或者它可以在建構時接受 func(K) int64，並使用它來雜湊其金鑰。如果需要更多函式，可以將持有這些函式的結構宣告為偽合約，然後將它們傳遞給通用函式。這讓 Go 的多型變得簡單、明確，並為未來關於合約或其他機制的進一步創新留下了空間，同時允許立即實現泛型類型的絕大多數好處。
Christoph Hack：我剛看了 Alexandrescu 的最後一場演講 The next big Thing。他表示「概念是浪費時間」，並提出了一個完全不同、更強大的方向（甚至與當今 C++ 中所有可能的方向相比）。Go 已經具備了大多數必要的特點，例如反射和測試類型是否實作了可選介面。唯一缺少的是程式碼產生。例如，json.Marshal 使用反射運作得很好，但如果它也可以（選擇性地）透過實作一個由編譯器自動呼叫並執行一般 Go 程式碼的 Go 函式來產生程式碼，我們將擁有一切。這乍聽之下可能很瘋狂，玩具範例看起來可能很冗長，但我認為 Alexandrescu 在這裡有道理。例如，只要想想 gqlgen 與其他基於反射的 graphql-libs。請觀看他的演講！
Bodie Solomon：我發現泛型設計有點令人困惑且不透明。請考慮整合一些來自 Zig 的精緻編譯時間函式的概念！Go 2 泛型的設計很巧妙，但我覺得它違背了 Go 傳統上簡單執行時間語意和簡單語法之間的緊密結合。此外，Go 最大的問題之一是它無法擺脫 GC 和執行時間，這使得它無法成為我可能想使用它的各個地方的可行競爭者。我強烈希望 Go 2 能夠引入僅編譯時間的泛型，這樣我就可以可靠地避免在不想要動態介面的地方使用它們，而無需依賴程式碼生成。不幸的是，這看起來將由編譯器決定，而無需我的輸入。請至少考慮讓使用者能夠將泛型限制為僅編譯時間解析，或許作為契約的屬性，拒絕編譯動態類型以滿足契約。
Dag Sverre Seljebotn：C++ 有個很大的問題，就是人們濫用元程式設計（「泛型」）來進行編譯時間元程式設計。我真的很希望 Go 能走上 Julia 的道路，它提供了衛生的巨集。即使它被嚴格地保留在編譯時間障礙上，並且沒有執行時間程式碼生成，這至少可以避免我們在 C++ 世界中看到的所有不良傾向，這些傾向來自於它們的範本系統。你可以使用泛型來做的事情，你通常也可以使用巨集來完成（例如，SortSliceOfInts = MakeSliceSorterFunctionMacro!(int) 可以產生一個新的函式來排序一組整數）。連結：https://julia-docs.dev.org.tw/en/v0.6.1/manual/metaprogramming/
Maxwell Corbin：討論和開放問題部分中提出的問題，都可以透過在套件中定義泛型，而不是在函式或類型層級中定義來避免。原因很簡單：類型可以參照自己，但套件無法匯入自己，而且雖然有很多方法可以演算法產生更多類型簽章，但你無法對匯入陳述式執行相同的操作。此類語法的快速範例可能是
```
\\ list
package list[T]

type T interface{}

type List struct {
    Val T
    Next *List
}

// main
package main

import (
    il "list"[int]
    sl "list"[string]
)

var iList = il.List{3}
var sList = sl.List{"hello"}

// etc...
```
範例中的語法可能不必要地冗長，但重點是部落格文章中所有不幸的程式碼範例，甚至都不是合法的建構。套件層級泛型避免了元程式設計最嚴重的問題，同時保留了大部分的實用性。
Andrew Gwozdziewycz：由於 contract 一詞會讓「合約」一詞過載，就像在契約設計中一樣，因此使用這個詞會讓我猶豫。雖然泛型使用案例與 DbC 中的「合約」有些相似，如果你瞇著眼睛看的話，但這些概念卻大不相同。由於「合約」是電腦科學中既定的概念，因此我認為使用不同的名稱，例如 behavior 或 trait，會減少許多混淆。設計文件也建議了為什麼使用 interface 並非理想的原因，不過，Go 的合約機制似乎是介面的延伸，太過明顯，無法這麼快就忽視… 如果可以執行 interface setter(x T) { x.Set(string) error } 和 interface addable(x T, y U) { x + y }，看起來似乎很自然且易於理解。
- Russell Johnston：同意合併合約與介面會很棒。解決運算子命名問題的另一種方法可能是為運算子提供一些標準介面，其主體無法用一般的 Go 程式碼表示。例如，標準的 Multipliable 介面將允許 * 和 *= 運算子，而標準的 Comparable 介面將允許 ==、!=、<、<=、>= 和 >。為了表示具有多種型態的運算子，這些介面可能需要型態參數，例如：type Multipliable(s Self /* 這是所有介面上隱含存在的 */, t Other) interface { /* 由語言提供 */ }。然後，使用者撰寫的介面/合約可以使用這些基於識別碼的標準名稱，巧妙地避開設計文件中提到的關於語法和型態的問題。
- Roberto (empijei) Clapis：我同意這一點，並且應該更清楚地說明在何處使用介面以及在何處使用合約。統一兩者會很棒，因為它們試圖解決重疊的問題。
- Kurnia D Win：我認為 constraint 比 contract 更好的關鍵字。就我個人而言，我喜歡 type addable constraint(x T, y U) { x + y }，而不是與介面合併。
Hajime Hoshi：我感覺建議的提案對於我們想要解決的問題來說太龐大了，這些問題列在 https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md 中。我擔心這個功能會被濫用並降低程式碼的可讀性。抱歉，如果我遺漏了什麼，但提案中並沒有提到 go generate。go generate 不足以解決這些問題嗎？
Stephen Rowles：我發現方法語法難以解析，作為閱讀它的人類，使用不同的括號類型來表示型態區段可能會更清楚，例如：我也一樣 👍 +1。再一個 👍 +1（Pasha Osipyants）。
```
func Sum<type T Addable>(x []T) T {
    var total T
    for _, v := range x {
        total += v
    }
    return total
}
```
yesuu：在此範例中，將 T 視為參數名稱，將 type 視為參數類型。顯然將 type 放在後面較為合理，且合約後接 type，例如 chan int。
```
func Sum(T type Addable)(x []T) T
```
- Roberto Clapis：請閱讀此區段
  - 老實說，這看起來有點逃避。它說「通常」，這表示一定已有一些例外。Go 有一個清晰的語法，讓程式碼易於閱讀且團隊易於協作。我認為為了讓程式碼可讀性更好，讓解析器更複雜是值得的。對於大型且長期執行的專案，程式碼的可讀性，以及因此產生的可維護性，至關重要
  - 這個呢？這個
Seebs：回饋有點長，無法內嵌，2018 年 8 月。摘要基本上是「我希望找到一種方法，為兩種類型中的每種類型指定一個合約，而不是為兩種類型指定一個合約」，以及「我比較喜歡 map[T1]T2，而不是 t1var == t1var，作為「T1 必須是允許的地圖金鑰」的標準形式。
Seebs：如果合約就是類型參數化函式會怎樣？（2018 年 9 月 1 日）
西恩·奎蘭：我發現合約語法相當令人困惑。對於一個假設定義了確切需求且將成為 API 文件一部分的事物，它可能包含各種各樣與合約無關的廢料。此外，引用設計：「我們不需要解釋合約主體中可能出現的每個陳述的含義」。這似乎與我對合約的期望相反。在我看來，將函數主體複製到合約中並讓它運作似乎是一個錯誤，而不是一個特點。就我個人而言，我更喜歡統一介面和合約的模型。介面感覺更接近我想要的合約樣式，而且有很大的重疊。許多合約似乎也將是介面，這是否合乎情理？
諾迪爾·圖拉庫洛夫：請詳細說明

像 container/list 和 container/ring 這樣的套件，以及 sync.Map 這樣的類型，將更新為編譯時類型安全。

和

math 套件將擴充套件，為所有數字類型提供一組簡單的標準演算法，例如廣受歡迎的 Min 和 Max 函數。

或理想地新增一個關於現有類型/函式的轉換/遷移部分，以使用類型多態性。FWIU 將類型參數新增到現有類型/函式很可能會中斷使用類型/函式的現有程式。math.Max 將如何確切地變更？目的是進行向後不相容的變更，並撰寫工具以自動將程式碼轉換為 Go2 嗎？對於提供目前使用 interface{} 執行函式和類型的其他函式庫的作者，一般建議是什麼？是否考慮類型參數的預設值？例如，math.Max 的類型參數預設為 float64，而 "container/list".List 的類型參數預設為 interface{}
Ward Harold：即使只是為了完整性，Modula-3 泛型設計應納入其他語言中的設計部分。Modula-3 是一種美麗的語言，但遺憾的是在錯誤的時間推出。
- Matt Holiday：同樣提到 Alphard 語言，它與 CLU 大約在同一時間開發，也影響了 Ada 設計。請參閱 Alphard：形式與內容，Mary Shaw 編輯，Springer 1991，以取得各種收集的論文和一些補充資料。Alphard 和 Ada 是我認識泛型程式設計的開端。Go 能否在等待 40 年後，終於擊敗 C++ 提供合約？
Ole Begemann：您在泛型概觀頁面上寫道：「Swift 在 2017 年發布的 Swift 4 中新增了泛型。」這並不正確。Swift 自 2014 年首次公開發布以來就有了泛型。證據（僅舉一例）：WWDC 2014 中 Apple 開發人員關於 Swift 的演講記錄，其中詳細討論了 Swift 的泛型功能。

這也不正確：「Equatable 看起來是 Swift 中的內建函式，無法以其他方式定義。」Equatable 協定是在 Swift 標準函式庫中定義的，但它沒有什麼特別之處。完全可以在「一般」程式碼中定義相同的事物。
Kevin Gillette：2018 年 8 月 30 日「合約」草稿的更正

check.Convert(int, interface{})(0, 0) 的一個實例應改為 check.Convert(int, interface{})(0)，或提供說明，說明為何函式應使用兩個零而不是一個零。
Adam Ierymenko：我有一個在 Go 中執行有限運算子重載的想法，這可能會讓此提案對數值程式碼更有用。它很大，所以我把它貼在 Gist 中。
- DeedleFake：我完全同意反對運算子重載的論點，而且我相當高興 Go 沒有它，但我同時也認為，無法透過合約解決 a == b 和 a.Equals(b) 之間的差異，是目前草案設計中最大的問題。這表示你仍然會為相當多的東西撰寫多個函式。例如，試著撰寫一個二元樹。你應該使用 t < t 或 t.Less(t) 的合約嗎？對於一個加總函式，你應該使用 t + t 或 t.Plus(t) 嗎？不過，我絕對想要一個不涉及運算子重載的解決方案。或許可以有一個指定適配器的方法，基本上來說是 如果一個滿足合約 A 但不滿足合約 B 的類型 T，用於一個受合約 B 約束的參數，請對其套用這個方法，以使其滿足合約 B。例如，合約 B 可能需要一個 Plus() 方法，而合約 A 則需要使用 +，因此適配器會自動將使用者指定的 Plus() 方法附加到 T，以在該合約下使用其期間。
  - 一個可能適用於此提案的東西是一個 equal(a, b) 內建函式，如果存在 a.Equals(b)，它會使用 a.Equals(b)，否則使用 a == b，如果類型無法比較，則編譯失敗（其他運算子也一樣）。這太奇怪了，無法認真考慮，但它會與合約搭配使用，並允許迴避具有運算子與無法具有運算子的類型之間的不對稱性，而不引入運算子重載 —jimmyfrasche
  - 另一個想法是明確可重載的運算子：a + b 不可重載，但 a [+] b 可以重載。它會對基本類型使用正常的 +，但如果存在的話，它會對物件使用 Operator+() 等。我確實認為，沒有任何健全形式的運算子重載或類似形式的泛型，其用處會少很多，以至於你甚至可以不用這麼做。-Adam Ierymenko（原發文者）
- Ian Denhardt：DeedleFake 概述了沒有運算元重載的問題，我想建議將重載「公開」的提案是錯誤的想法；相反地，我們應該限制哪些運算元可以重載到滿足這些條件的運算元
  1. 運算元的語意可以理解為方法呼叫。數字上的大多數運算元通過此測試；big.Add 仍然是加法，因為我們從 int32、uint64 等得知。未通過此測試的運算元範例為 && 和 ||；這些是短路運算，沒有函數或方法可以複製。無論如何看待，它們基本上都不是方法，不應被方法覆寫。我認為運算元重載之所以會受到批評，部分原因在於 C++ 允許你覆寫所有內容，包括逗號運算元等奇怪的東西。
  2. 應該有明確的用例來覆寫它們。同樣地，算術運算元通過此測試，以及 < 和相關運算元。指標解除參考通過第一個測試，但我很難想出實際上看起來像好點子的「其他類型的指標」的用途。它們在 C++ 中更合理，但垃圾收集指標基本上已經涵蓋了你。
  3. 運算元的正常含義應該是容易理解的事情。例如，指標是錯誤的根源，而 *foo 執行除了從記憶體位址讀取之外的其他操作的可能性，會讓已經很困難的除錯工作變得更困難。另一方面，+ 可能會呼叫 big.Add 的可能性是相對獨立的，而且不太可能造成很大的混淆。
  4. 最後，標準函式庫必須設定一個好範例；覆寫 + 的方法在概念上應該是加法，例如。C++ 在這裡走錯了路，定義了道德上為 os.Stdout.ShiftLeft("Hello, World!") 的內容。
Eltjon Metko：是否可以在函數參數內，在類型識別碼之後指定合約？這樣就可以推斷出 T 是什麼，並且可以消除第一組括號。
```
func Sum(x []T:Addable) T {
    var total T
    for _, v := range x {
        total += v
    }
    return total
}
```
Tristan Colgate-McFarlane：經過一番反覆思考後，我大致上贊成這項提案。合約的語法限制可能比較好，但我認為應該允許參照特定欄位（而不僅僅是某些人建議的方法）。如果可以採取任何措施，讓相容的介面和合約更容易互用，那會很好（儘管我認為可能不需要額外的規格）。最後，我認為值得考慮棄用介面類型。儘管很激進，但合約基本上也允許指定行為。任何限制該行為的合約限制（例如參照套件中的其他類型）都應該解除。合約似乎是介面的嚴格超集，我通常反對有兩個重疊的功能。還應該考慮一個有助於撰寫介面的工具。
Patrick Smith：我們可能會考慮在定義泛型類型的函數時，需要 type 關鍵字。這使得程式碼稍微冗長一點，但更清晰且更一致（現在類型參數總是置於 type 關鍵字之前）。
```
func (x Foo(type T)) Bar()
```
Patrick Smith：在此範例中，Foo(T) 是內嵌在 Bar(T) 中，還是 Bar(T) 有個名為 Foo 的函數？
```
type Foo(type T) interface {}
type Bar(type T) interface {
        Foo(T)
}
```
Xingtao Zhao：提案中有太多圓括號。提案中提到「[]」在某些情況下是模稜兩可的。但如果我們使用 [type T, S contract]，就不再有任何模稜兩可之處。
Dave Cheney：先前的類型函數提案顯示，類型宣告可以支援參數。如果這是正確的，那麼建議的合約宣告可以從
```
contract stringer(x T) {
    var s string = x.String()
}
```
至
```
type stringer(x T) contract {
    var s string = x.String()
}
```
這支持 Roger 的觀察，即合約是介面的超集。type stringer(x T) contract { ... } 以 type stringer interface { ... } 介紹新介面類型的方式，介紹新的合約類型。
- jimmyfrasche：不過，合約並非類型。您無法擁有 stringer 的值。您可以擁有 stringer 類型的值。這是一種元類型。類型是值的一種謂詞。您詢問編譯器「這個值是 string 嗎？」，而編譯器回答「是」（允許編譯繼續）或「否」（停止並告訴您錯誤）。合約是類型向量的謂詞。您詢問編譯器兩個問題。這些類型是否滿足此合約？然後：這些值是否滿足這些類型？介面透過儲存 (type, value) 對來模糊這些界線，前提是類型有適當的方法。它同時是類型和元類型。任何不使用介面作為元類型的泛型系統，都不可避免地會包含介面的超集。雖然完全有可能定義一個專門使用介面作為元類型的泛型系統，但這表示失去撰寫使用介面無法討論的事物的泛型函數的能力，例如運算子。您必須將可以詢問類型的問題限制在它們的方法集中。（我對此沒意見）。
btj：在設計文件草案的其他語言設計部分中，缺少兩個非常重要的項目：具有類型類別的 Haskell，以及具有隱式引數的 Scala。
iamgoroot：讓類型別名支援更完善，並讓使用者選擇泛型，這不是自然而然的事嗎？而且你不需要太多語法就能做到

type Key _
type Value _

type IntStringHolder Holder<Key:int, Value:string>

type Holder struct {
    K Key
    V Value
}

func (h *Holder) Set(k Key, v Value) {
    h.K = k
    h.V = v
}

func main() {
    v:= IntStringHolder{}
    v.Set(7,"Lucky")
}

antoniomo：雖然草案清楚說明了為什麼捨棄 F<T>、F[T] 和非 ASCII（無法在此輸入）F<<T>>，但感覺 F{T} 比有時連續出現三個 () 更容易閱讀，而且不會讓解析器因為無法在這種情況下開啟區塊而複雜化非受限的展望。
aprice2704：我真的很不喜歡使用一般括號 ( 的想法，雙字元序列會因為非受限的展望而造成編譯器負擔嗎？<| 和 |> 呢？它們會運作嗎？它們的優點是與 ( 非常不同，在 ascii 中視覺上有些意義，而且在我於 VSCode 中使用的「Fira Code」字型（強烈推薦）中，有連字可以將它們呈現為指向右或左的小三角形。
leaxoy：首先，我對於編輯頁尾感到抱歉，但我無法移除頁尾內容。我的意見是：大量的 ( 和 ) 讓 Go 看起來很雜亂，< 和 > 就像其他語言一樣好，而且對來自其他語言的人來說更友善。
Hajime Hoshi：我完全同意 aprice2704 的語法疑慮。例如，[[ / ]] 不會運作嗎？

此內容是 Go Wiki 的一部分。