為什麼 Python、Go 和 Rust 都不支援三元運運算元？

在程式設計時，我們經常要作條件判斷，並根據條件的結果選擇執行不同的語句塊。在許多程式語言中，最常見的寫法是三元運運算元，但是，Python 並不支援三元運運算元，無獨有偶，兩個最熱門的新興語言 Go 和 Rust 也不支援！

為什麼 Python 不支援三元運運算元呢？本文將主要分析 Python 在設計條件選擇語法時的過程，科普為什麼它會採用現今的與眾不同的實現方案，同時，我們也將考察為什麼其它語言也要拋棄傳統的三元運運算元。

在開篇之前，我再宣告一下：就像「Python為什麼」系列的大部分文章一樣，本文關注的僅是一個很小的語法點，但它並不是「茴香豆有幾種寫法」那種毫無意義的話題。因為，細微之處見真功夫，深入研究語言設計背後的原因、歷史和哲學，可以讓我們在程式設計時有更加清晰和自由的思維。

什麼是三元運運算元？

三元運運算元通常指的是「?:」，其語法形式為：condition ? expression1 : expression2，如果 condition 為真，則取 expression1，若不為真，則取 expression2。

語法簡化形式「a ? b : c」，可以讀成「如果 a 條件成立，則為 b，否則為 c」。

三元運運算元是對普通一重 if-else 結構的簡化，常用於在一條語句中同時實現條件判斷和取值操作。

// 常規 if-else 
if (a > b) {
    result = x;
} else {
    result = y;
}

// 簡化後的寫法
result = a > b ? x : y;

採用了這種語法設計的程式語言有很多，比如 C、C#、C++、Java、JavaScript、PHP、Perl、Ruby、Swift 等等。毫無爭議，它就是程式語言界的主流設計方案（至今仍是）。

這種語法非常簡潔高效，程式碼的可讀性也很強（如果你不是第一次接觸的話），深得很多人的喜歡。

但是，它並非毫無缺點。Python 是這種語法設計的最著名的挑戰者，接下來，我們將看看為什麼 Python 要另闢蹊徑。

Python 社群的投票

Python 釋出於 1991 年，但在接下來的 15 年裡，除了 if-else 語法外，它並不支援三元運運算元和其它條件表示式。而且，在 2006 年引入條件表示式前，社群對此進行了漫長而曲折的爭論，可以說這是一個設計得很艱難的語法了。

最初，由於時常有人請求新增 if-then-else（三元）表示式，因此在 2003 年 2 月，PEP 308 – Conditional Expressions 被提了出來，目的是讓社群選出一個讓多數人支援的方案。

很快，除了少部分人希望啥也不做外，社群裡出現了好幾種方案：

（1）使用標點符號構建的三元運運算元

即常規的三元運運算元，跟前文介紹的語法一樣：

<condition> ? <expression1> : <expression2>

這個方案的呼聲挺高，有開發者甚至已提交了實現程式碼。但是，Guido 給出了兩個反對的理由：冒號在 Python 中已經有許多用途（即使它實際上不會產生歧義，因為問號需要匹配冒號）；對於不習慣 C 衍生語言的人來說，理解起來很困難。

（2）使用現有和新的關鍵字構建

引入新的「then」關鍵字，結合現有的「else」關鍵字：

<condition> then <expression1> else <expression2>

它的優點是簡單明瞭、不需要括號、不改變現有關鍵字的語意，不大可能與語句混淆，而且不需要過載冒號。缺點是引入新關鍵字的實現成本較高。

（3）其它思路

跟上一種方案的思路相似，但沒有上述兩類方案的支援度高。

(if <condition>: <expression1> else: <expression2>)
<condition> and <expression1> else <expression2>
<expression1> if <condition> else <expression2>
cond(<condition>, <expression1>, <expression2>)

值得一提的是(if <condition>: <expression1> else: <expression2>) ，它是常規 if-else 語法的扁平化，容易理解，但缺點是需要使用圓括號，容易跟生成器表示式混淆，而且需要直譯器對冒號做特殊化處理。

另外值得一提的是<expression1> if <condition> else <expression2>，它是 PEP-308 最早版本的推薦方案，但是這種不將條件放在首位的風格讓一些人感覺不舒服，而且，當「expression1」很長的時候，很容易就忽略掉它的條件。

當時參與投票的全部設計方案：

總體上，開發者們希望引入某種形式的 if-then-else 表示式，但投票後卻沒有哪種方案能取得絕對的優勢。概括起來，分歧的問題主要有：是否用標點符號、是否複用關鍵字、是否複用圓括號、是否引入新關鍵字、是否引入新語法……

由於得票太分散，因此，這個 PEP 在當時被拒絕了。PEP 中寫道：「Python 的一個設計原則是在不確定採取哪條路線時，則保持現狀。」

and-or 用於條件選擇的問題

以上的投票事件發生在 2004 年 3 月，但是，在 PEP 被拒絕後，相關話題的討論並未平息，因為大家總想找一種簡潔的方式來替換「if-else「。

時間到了 2005 年 9 月，郵件組中有人提議在 Py3.0 中變更"and"與"or"操作符的邏輯，提議將"and" 和 "or" 運運算元簡化成始終返回布林值，而不是返回最後一個被求值的引數。

之所以發起這個提議，原因是他使用了<condition> and <expression1> or <expression2>的方式來實現條件判斷與選擇。但是這種寫法在 Python 中的行為跟有些語言並不一樣，使用不嚴謹的話，可能會釀成 Bug！

看看下面的兩個例子，你覺得它們會得到什麼結果呢？

a = True and True or "Python貓"

b = True and False or "Python貓"

對於<condition> and <expression1> or <expression2> ，若 condition 為假，則會直接對 expression2 求值並返回結果；若 condition 為真，則先對 expression1 求值，若也為真，則不會繼續對 expression2 求值，若 expression1 不為真，則對 expression2 求值。

因此，上述例子得到的 a 是「True」，而 b 會得到「Python貓」。

本系列的《Python 為什麼能支援任意的真值判斷？》介紹過 Python 在真值判斷的特殊之處，運用到以上結構中，將出現更不易察覺的問題。比如，該郵件的作者就是遇到了「expression1」為複數「0+4i」，這個數的真值判斷為 False，因此導致最後返回的不是預期的「expression1」，而是「expression2」！

在沒有更好的方案前，「and-or」是比較常見的條件選擇寫法，PEP-308 也提及了它，也指出了當「expression1」為假的情況，還認為這種方案是醜陋和令人費解的。

這封郵件再次引發了社群對條件選擇語法的討論，大佬們紛紛登場。

以我現在的視角分析，其實就是開發者們不滿足於「if-else」的現狀，但是當時流行的「and-or」寫法並不夠好，因此，大家期望 Python 設計出新的規範性語法，來解決這個痛點。

與眾不同的條件表示式

在經過 10 天的郵件討論後，Guido van Rossum 最終決定新增一個條件表示式，語法形式為X if C else Y 。因此，PEP-308 被重開和更新，並很快就在次年的 2.5 版本中實現了。

前文已提到過這個讓一些人感覺不舒服的方案了，因為它沒有將條件判斷邏輯放在最前面。

那麼，為什麼最後的勝者會是它呢？這是不是最優的設計呢？

不可否認，起到決定性作用的原因是 Guido。由於社群在一年半前投票時沒有形成多數意見，因此他行使 BDFL （終身仁慈獨裁者）的決策權力，裁定出一個他認為是最佳的方案。

X if C else Y 非常易於理解，可讀性高。它延續了「明確優於隱式」的風格，使用了直觀口語化的「if-else」，而不是引入可能引起混淆的標點符號，就像 Python 選擇「and」和「or」兩個單詞，而不是「&&」和「||」兩個符號，它們有著異曲同工之妙。

雖然調整後的語法順序讓人不太習慣，但其實這樣的實現卻大有好處。首先，它只需複用「if-else」兩個關鍵字，而不需要引入「then」、「when」和其它語法要素，也不像(if <condition>: <expression1> else: <expression2>) 那樣的繁瑣。

其次，為了驗證X if C else Y 的有效性，Guido 排查了標準庫中所有「and-or」組合的寫法，發現那些C and X or Y 寫法都可以被X if C else Y 替換掉。標準庫的情況，證明了這新的語法是可行的。

最後，在 PEP-308 提及的原因外，我還想補充一點。據觀察，我發現很多時候我們有一個已初始化的變數，然後需要在出現某個條件時，更新變數的值。在這種情況下，「else」部分可以被省略，非常便捷。

my_str = ""
# 中間存在其它程式碼邏輯
# 當 condition 為真時，變數會被重新賦值
my_str = "Python貓" if condition

回顧這段歷史，我們可以梳理出一條線索：Python 沒有設計三元運運算元「?:」，主要是因為它不符合 Python 明確直觀的設計風格。最後採用X if C else Y 這種設計，主要的意圖其實是消除「and-or」寫法的隱患，這種設計簡明易讀，而且還有<expression> if <condition> 簡化寫法的妙用。

總體而言，Python 設計者非常看重可讀性與可維護性，不採用三元運運算元而創造條件表示式語法，這是一個經過了開放討論、謹慎評估與權衡取捨的結果。

Go、Rust 為什麼不支援三元運運算元？

考察完 Python 的設計原因後，我們再來考察「反派陣營」中兩門最熱門的語言。

首先是 Go 語言，官網的 FAQ 專門列出了一個問題：「Why does Go not have the ?: operator?」。

Go 語言不支援「?:」運運算元，而是推薦使用原生的「if-else」寫法。檔案的解釋很簡短，只有一段話：

Go 語言沒有 ?: 運運算元，因為語言的設計者們經常看到它被用來建立難以理解的複雜表示式。雖然 if-else 形式比較長，但是它無疑更清晰易懂。一個語言只需要一個條件控制流結構。

接著是 Rust 語言，它的官方檔案中似乎沒有任何關於不支援三元運運算元的解釋。但在查閱資料後，我發現它也有一段特殊的故事，非常有意思：在 2011 年 6 月時，Rust 曾經引入過三元運運算元（#565），然而半年後，設計者意識到這個特性是多餘的，因此又把它移除了（#1698、#4632）!

為什麼三元運運算元在 Rust 是多餘的呢？因為它的 if 語法並不像其它語言是「語句（statement）」，而是一個「表示式（expression）」，這意味著你可以直接將 if 表示式賦值給變數：

// 若條件為真，得到 5，否則 6
let number = if condition { 5 } else { 6 };

這種語法形式足夠簡單明瞭，不就是將大家都熟悉的「if-else」直接用於賦值麼，太方便了，替換成三元運運算元的話，確實有點畫蛇添足之感。

另外，Rust 使用花括號劃分程式碼塊，因此上例的花括號內可以包含多條表示式，也支援換行，例如這個例子：

let x = 42;
let result = if x > 50 {
    println!("x is greater than 50");
    x * 2 // 這是一個表示式，將返回的值賦給 result
} else {
    println!("x is less than or equal to 50");
    x / 2 // 也是一個表示式，將返回的值賦給 result
};

這種用法，Python 是不可能做到的。最關鍵的區別在於，Rust 的 if 是表示式而不是語句。

這兩個概念的區別是：

表示式（expression）通常指的是由變數、常數、運運算元等組成的一個可求值的程式碼片段，它的求值結果可以用到其它表示式或語句中。
語句（statement）通常指的是完成某個任務的單個指令或一組指令，例如賦值語句、條件語句、迴圈語句等，它沒有返回值（或者為空），不能用於賦值操作。

除了 Rust 外，還有一些程式語言中的 if 是表示式而不是語句，例如 Kotlin、Scala、F#、Swift，它們在理論上也不需要使用三元運運算元。（題外話：Swift 是個例外，它也有三元運運算元。Kotlin 有「?:」運運算元，注意兩個符號是連在一起的，val result = a ?: b 表示：如果 a 不為 null，則賦值給 result ；否則將 b 賦給 result）

由於有這種語言設計層面的區別，因此在面對「是否要支援三元運運算元」這個問題時，Rust 和 Python/Go 的思考角度有著天然不同的起點。知道了這種區別後，我們對程式語言會有更明晰地認知。

回到本文的問題：為什麼有些程式語言不採用主流的三元運運算元語法呢？

不可否認，「?:」確實是一種簡潔好用的設計，然而，標點符號的負面影響是過於抽象，可讀性並不及「if-else」那樣強。另外，不同語言的設計風格與使用習慣，也會導致不同的選擇。

Python 在經過一番波折後，最後設計出了與眾不同的條件表示式。Go 語言明確表示不支援三元運運算元。Rust 先設計後捨去，主要的原因在於 if 表示式的語言基礎。

考察完這三個熱門語言後，我相信你已收穫了一個滿意的答案。如果是這樣，請點贊支援一下本文吧！

最後，本文出自「Python為什麼」系列，全部文章已歸檔在 Github 上，歡迎 star 和提 issue。