在這個問題中，出現了一個問題，可以通過將使用通用類型參數的嘗試更改為關聯類型來解決。這提示了一個問題“為什么關聯類型在這里更合適？”，這使我想知道更多。引入關聯類型的RFC表示：該RFC通過以下方式闡明了特征匹配：將所有特征類型參數視為輸入類型，以及提供關聯的類型，它們是輸出類型。RFC使用圖結構作為激勵示例，并且在文檔中也使用了圖結構，但我承認，與類型參數化版本相比，我不完全意識到關聯類型版本的好處。最主要的是，該distance方法不需要關心Edge類型。很好，但是似乎根本沒有關聯類型的原因。我發現關聯類型在實踐中使用起來非常直觀，但是當我決定在自己的API中何時何地使用它們時，我發現自己很掙扎。在編寫代碼時，何時應在泛型類型參數上選擇關聯的類型，何時應相反？