RFC#2457——Rust 語言支持非 ASCII 碼標識符在 GitHub 引起的激辯（一）

Everything from Python to C++ supports non-ASCII idents by default. It's the correct behaviour. —— Graydon Hoare，Rust語言設計者python

譯：「從Python到C++都默認支持非 ASCII 碼標識符。這是正確的做爲。」編程

2018年10月31日，Rust 語言歷史上最受爭議的 RFC 之一在經歷了將近5個月的爭辯和修訂後，終於圓滿完成。swift

684條評論，75人蔘與。雖未親歷，但前事不忘後事之師。此文就來回顧這個 RFC 以及那些激烈碰撞的聲音。api

什麼是非 ASCII 碼標識符

ASCII 碼問世於20世紀六十年代。標準 ASCII 碼只有 128 個，僅包含了英文字符與其餘少許標點、運算等特殊符號。多數現今經常使用的編程語言在上世紀被設計出來時，設計者和使用者也大多數在英文母語國家，所以早期並不支持使用英文以外的語言文字來命名代碼中的標識符。markdown

時至今日，有很多國內開發者還認爲，在代碼中必須用英文命名變量，所以代碼中會出現 redEnvelope 甚至 hongbao 這樣的命名。編程語言

但實際上大多數英文編程語言早已支持使用英文以外的字符命名變量、方法、類名等等。好比 Python3 中徹底能夠這樣寫：編輯器

紅包金額 = 888
紅包數 = 5
開銷 = 紅包數 * 紅包金額
複製代碼

蘋果公司主導的 Swift 編程語言官網的手冊中，也用了中文和其餘符號進行命名演示：ide

![2019-11-14_swift入門命名]({{ "/assets/2019-11-14_swift入門命名.png" | absolute_url }})

此文的主角，RFC#2457 就是爲了讓 Rust 語言也具有這一特性。函數

RFC#2457

2018 年六月三日 10 點 25 分（太平洋時間）， PR 2457 被 pyfisch 建立，開始了這個 RFC 的審議過程。工具

題目很直接：「Allow non-ASCII identifiers」——「容許非 ASCII 標識符」。在它的初稿中，在「動機」部分開篇，指出了「許多開發者的英文並不流利，使用母語命名標識符使得寫和讀代碼更輕鬆。」

更引用了 Python 語言於 2007 年的 PEP 3131：

Such developers often desire to define classes and functions with names in their native languages, rather than having to come up with an (often incorrect) English translation of the concept they want to name. By using identifiers in their native language, code clarity and maintainability of the code among speakers of that language improves.

（並不熟悉英文語言的）開發者常但願用他們的母語定義類和函數，而不是被逼着用（每每是不正確的）英文翻譯來命名一個概念。經過用母語命名標識符，對同一母語的開發者來講，代碼清晰度和可維護性得以改進。

RFC 的更多篇幅包含相關的技術細節，有興趣的能夠深究。本文更關注的是 684 個評論中佔大多數的對該 RFC 初衷的質疑（尤爲是來自於華人開發者的）以及相應迴應。

風波起

RFC 提交審議的當日下午4 點，一位 Rust 項目參與者 mark-i-m 提出了首個異議，表示（非 ASCII 碼）字符難打以及有時會顯示亂碼。並在以後用教學經歷闡釋：有時學生從網上拷貝的代碼段中有沒法顯示的 unicode 字符（其中誤稱 Java 不支持非 ASCII 碼標識符）；有位教授喜歡用希臘字符在 Julia 代碼中命名，而 ta 本人輸入這樣的字符很是麻煩。

接着，一位標示爲中國廣州的學生 shingtaklam1324 提出，中文字符會在不支持 unicode 的某些編輯器上變爲亂碼。pyfisch 迴應：編譯器支持 UTF-8 編碼的源代碼文件，修改編輯器設置便可。

四日 10 點，一位 Rust 組織成員 joshtriplett 提出我的立場：但願標識符命名僅限於 ASCII。他以後發佈了一系列跟帖，在七月二十六的總結中，提到他因爲源碼中出現非 ASCII 碼的字符致使各類調試的麻煩，但未給出具體例子。他在四日的一個帖中的發言頗有表明性：

It's a tradeoff between "should people be able to write identifiers in languages that can't be represented in ASCII" versus "should people be able to read arbitrary code". Both of those are important, and I don't want to discount either, but I'd favor the latter.

在「人們能用英文以外的語言寫標識符」和「人們能讀懂任何代碼」之間權衡，雖然二者都很重要，但我更偏向後者。

這種「天下皆（應）會英文」的思惟很常見，彷佛英文標識符就能被世界上全部人讀懂。要知道，世界上有八成多的人口並不會英文。

馬上，來自 Mozilla 的開發者 SimonSapin 迴應：

it is up to the author of a given piece of code to make that choice. It is not our place to dictate what language people should speak or write in contexts we can’t even think of.

這（用母語仍是英文命名）應該是代碼做者的選擇。咱們（語言設計者）並不應裁斷開發者用什麼語言讀寫代碼，尤爲是在咱們料想不到的場景下。

5 日，Ixrec 提問：「真的會有人在實用項目代碼中用非 ASCII 標識符嗎？」他還提到，他是佔全世界會日語的 58% 的美國男士之一，但他也想不到除了日語在寫註釋以外的用處。

來自 Mozilla 的 Manishearth 迴應稱，代碼中看到過一些歐洲語言如葡萄牙文；暫沒看到中文或俄語的，但看到過註釋中使用。有些日語和葡萄牙語英文化後的代碼，可見的確有使用非 ASCII 碼命名的需求。另外，中國有個龐大的 Rust 社區，並未與英語 Rust 社區有太多交流。他在中文 Rust 的 QQ 羣衆徵求過相關意見，有幾方面收穫：

限於工具，代碼中不用中文
有時在新手教程中使用
大多數人不用中文命名

他的結論是，至少益處是使得音調可使用，好比 método。

接下來是來自中國廣州的 huangjj27 指出，輸入法切換會下降寫代碼的效率。不過也提到更多人會所以學 Rust。但願將此特性做爲選項，而非標配。

又一位座標北京的 crlf0710 表示，大陸主流沒有使用非 ASCII 碼命名。偶爾用拼音的會被認爲不專業。易語言有用戶，但並未進入主流。新手教程有用，但也許須要更名關鍵字，使文字看起來更一致。也但願特性做爲用戶可選項，而非標配。

又是北京的 ZhangHanDong 乾脆來一句「絕對不要！」

座標加州的 KiChjang 表示，一些中國 Rust 用戶擔憂生態被分裂。好比某個庫用的語言是用戶不知如何輸入的。

Manishearth 對此迴應：早已有大量庫除了命名以外的全部文檔都用非英文編寫，好比騰訊的 wepy，他就不會用。用了中文命名以後，也不會更糟。若是一個庫流行到有英文文檔的程度，極可能那時也會用英文命名了。至於若是庫用了不認識的語言，那就——不用。

至此，華人開發者，成爲一個批量發聲反對此特性成爲標配的羣體。

下面，Manishearth 得到一些葡萄牙 Rust 社區反饋，表示聽到不一樣意見。也獲得了一些使用葡萄牙語的代碼例子，包括 C++，Java 和 PHP。

來自韓國的 kimhyunkang 迴應 lxrec：以前在韓國公司工做時，看到一些 C++ 和 Java 開發者用英文化的韓語命名，緣由是需求文檔是韓文寫的，而很多術語很難翻譯成英文，由於韓語沒有從拉丁文或者希臘文借用的詞語，而英語沒有從中文借用的詞。若是要翻譯成英文，命名更長也更不可讀。

est31 提供了一些使用德文命名的 Java 和 PHP 代碼。

來自北京的 3442853561：工做中不該用（中文命名），但不支持的話會顯得 Rust 不合羣（不少其餘編程語言都支持），也對新手不友好。建議設置爲對新手默認使能，老手可關閉。

接下來是來自瑞士的 eggrobin 以他的用非 ASCII 碼和非英文標識符的親身經歷，包括在編寫編程書籍的例程中使用法語等等。

欲知後事如何，且聽下回分解！

【寫到這裏，已經三個多小時，遠遠超出了兩小時寫完的預計。而上面僅僅瀏覽了前三天內的 20 多個評論，已經有了不少收穫。決定分爲一個系列進行連載，如期待後文，敬請關注本號！】