PHP vs Go，為什么 Go 不支持命名參數調用函數？

作者：陳煎魚 2023-02-26 23:36:08

“為什么 Go 不能像 PHP、Python 一樣，在調用函數時，直接帶上參數名和值一起傳入。這樣就不用特意去看這個函數的形參的命名、類型等。明明 PHP8 都支持了？”

大家好，我是煎魚。

之前在《Go 語言設計哲學[1]》電子書中分享了《??為什么 Go 不支持函數重載和缺省參數？??》的思考和原因。最近有一位從其他編程語言轉型 Go 的同學提出了如下靈魂拷問。

今天針對命名參數這個特性展開思考，看看 Go 怎么回事。

命名參數

如果有了命名參數這個功能特性，在我們調用函數/方法時，傳入函數的參數不需要固定位置，位置可以隨意調整，名字對就行。甚至有的工具會基于此，做自動化的文檔等自描述的場景。

PHP8 的例子：

function hello(string $name, int $age) {
    echo $name, $age;
}

// 兩次調用的參數位置不一樣
hello(name:'煎魚', age:18);
hello(age:18, name:'煎魚');

理想中 Go 的例子：

package main

func sum(a int, b int) int {
 return a + b
}

func main() {
 resp := sum(a=7, b=28)
 println(resp)
}

由于不支持，運行編譯就會報錯：

./prog.go:8:15: syntax error: unexpected = in argument list; possibly missing comma or )

Go 必須是如下代碼：

func sum(a int, b int) int {
 return a + b
}

func main() {
 resp := sum(7, 28)
 println(resp)    // 輸出結果：35
}

也就是按函數所聲明的參數位置傳入，才能運行成功。

Go 語言在錯誤處理、函數重載以及缺省參數等社區議題討論時，總會祭出其的設計理念是：“顯式大于隱喻”，追求明確，顯式，要不就是 “less is more”。

每次看到只要不滿足這個理念的提案、討論，基本 Go 團隊可以圍繞這個論據給出一堆理由后拒絕掉。

本文提到的帶命名參數傳入函數，看起來非常顯式，很明確了。似乎很符合 Go 的設計哲學理念，感覺不應該沒有才對？

在 golang-nuts 郵件群組的多年討論中，涉及到以下幾類論據作為支撐：

這是一個語言設計和可讀性問題，“命名參數” 和 “缺省參數” 基本是成配套出現在語言設計中，需要一并考量合適與否。會出現一加就相當于要引入許多新語法特性了，能玩出騷操作。
引入這類特性會給 Go 帶來新語法復雜度，如果函數參數名修改了，那是不是破壞兼容性？是不是調用方全都得改一遍？如果出現同名的參數名，誰先誰后？怎么覆蓋？過長的話，函數調用會不會過于難接受？組合結構體覆蓋方法時，方法參數名需不需要保持一致？會產生一大堆新問題。
引入后會產生大量的函數可選參數（命名參數+缺省參數），原本只需要知道函數形參是什么，結果引入后需要查看名字、缺省值以及對應的缺省邏輯等，會加大程序員心智負擔。
編譯器本身不需要關注這些信息，為這個特性加大編譯器的各項開銷是不必要的，沒有理由讓編譯器在編譯代碼中存儲函數的參數名稱（需要具體考究深意）。

我們在討論中也有提到，這個特性可以借助 go:generate 的特性來實現類似的功能，有興趣的朋友可以看看 go-named-params[2] 這個開源庫。

顯然官方態度是，增加命名參數特性的弊大于利，貿然增加會影響到 Go 本身標榜的優勢（簡潔）。認為大可不必加，工具的問題需要讓工具自己解決。

在這篇文章中，我們針對其他編程語言既有的 “命名參數” 特性進行了分析和說明。顯然 Go 團隊在討論中，認為該項特性對于靜態語言，尤其對于 Go 團隊來講，似乎好處太少，加了會影響自己的風格（less is more），還可能會影響性能，真是大可不必。

各語言間的功能特性對比，是個老大難的問題。如果都一樣，那豈不是搞個大單體編程語言算了？這顯然是不現實的。

[1]Go 語言設計哲學: https://golang3.eddycjy.com/

[2]go-named-params: https://github.com/elliotchance/go-named-params

責任編輯：武曉燕來源：腦子進煎魚了