RFC-0088：RFC-0050 更新：FIDL 位元、列舉與限制語法

拒絕原因

由於提案中的變更並未明顯優於現況，因此遭到拒絕。

另請參閱：

• RFC-0050：FIDL 語法大改造
• RFC-0086：更新 RFC-0050：FIDL 屬性語法
• RFC-0087：更新 RFC-0050：FIDL 方法參數語法

「bits」和「enum」版面配置的新分隔線

這項 RFC 最初的動機是觀察到 RFC-0050：語法修訂指出，冒號是用來分隔版面配置和限制，但冒號在 bits 和 enum 宣告中用於劃分包裝型別時，會違反這項規則。最終，我們認為這種不一致性不夠模糊，無法證明僅為這兩種用途發明新語法，以移除冒號是合理的。

沒有任何建議的替代方案比半形冒號更好。我們考慮過以下選項：

• 單純移除半形冒號會造成混淆，因為第二種型別會修改 bits 或 enum 宣告，或「範本化」這些宣告。語法應會指出這種情況。
• 將包裝型別放在方括號中 (例如 bits<uint32> {...) 也會遭到拒絕，因為這與 FIDL 語言中其他角括號的使用方式不一致。尖括號目前用於包含版面配置參數，例如內建的 vector 版面配置由 vector<TYPE> 參數化，內建的 array 版面配置由 array<TYPE, SIZE> 參數化。但將包裝型別放在方括號中，會更類似於產生版面配置定義的範本，例如 (目前不支援的) struct<K,V>{...}。以這種方式混用角括號的意義，會造成混淆。
• 最後，只要將半形冒號換成新關鍵字 of 即可。這也不令人滿意，因為為了處理兩個非常輕微的極端情況，而向 FIDL 作者介紹新的認知負荷關鍵字，是划不來的交易。of此外，這也與目前使用的語法風格不同，後者偏向類似 C 語言的風格，而非受 ALGOL 影響的風格。

最後，大多數使用者可能會很快發現，這兩種情況是 layout : constraints 規則的特殊例外狀況，如 RFC-0050：語法修訂所述。

將限制清單括在方括號中

我們拒絕這項變更的原因有兩個：

• 語言會設定參數應顯示在角括號內的預期，無論參數 (版面配置或限制) 為何。使用方括號會違反這項預期。
• 根據 RFC-0086：FTP-050 更新：FIDL 屬性語法，FIDL 語法不再使用方括號。如果使用這種括號 (我們只有四種括號可用：圓括號、大括號、角括號和方括號)，來描述已使用角括號清楚說明的語法，就太浪費了。這只是非常小的變更，現有狀態不太可能在實務上造成混淆。

這只是非常小的變更，現有狀態不太可能在實務上造成混淆。

摘要

本文建議對 RFC-0050：語法改版中說明的語法進行兩項小幅更新。具體情形如下：

• bits 和 enum 版面配置的包裝型別定義不再需要使用半形冒號分隔版面配置指定碼和包裝型別。請改用新推出的 of 關鍵字做為分隔符。
• 限制清單現在會以方括號 (而非尖括號) 括住。

提振精神

我們正在導入 RFC-0050 定義的新語法，這正是對該標準進行最終更新的好時機。建議您一次完成大型語法遷移作業，而不是將變更分散到多個專案中 (RFC-0038：將版面配置與限制分開和 RFC-0039：型別排在第二位就是因為這個原因遭到拒絕，因此我們進行了大規模的全面修訂，最終產生 RFC-0050)。因此，建議將任何最終語法調整納入更廣泛的 RFC-0050 遷移作業。

「bits」和「enum」版面配置的新分隔線

RFC-0050 規定採用 layout:constraints 形式，也就是 FIDL 檔案讀取器應預期類型宣告中冒號左側的所有內容，都會影響位元組在連線上的排列方式，而右側的所有內容則是對該類型可能包含的值，強制執行的執行階段限制。目前，這項慣例有一個例外：位元/列舉宣告，這類宣告會將影響版面配置的資訊放在半形冒號右側。這會導致 FIDL 語法底層邏輯不一致。

將限制清單括在方括號中

如果是第二項變更，請考慮下列型別宣告：

vector<vector<zx.handle:<VMO,zx.READ,optional>>>

目前難以透過視覺方式剖析。一般類型規格和限制清單在許多方面都有根本上的差異 (一個會影響版面配置，另一個則不會；一個是必要固定大小的清單，另一個是選用且長度可變的清單，等等)，但目前是使用相同的語法算繪。這會造成 <...> 語法過載，且難以讀取深度巢狀定義。

設計

這項 RFC 指定了 FIDL 語法的兩項變更。

「bits」和「enum」版面配置的新分隔線

bits 和 enum 宣告的包裝型別定義不再需要前置冒號。而是導入新的 of 關鍵字做為分隔符，且僅在 bits 或 enum 關鍵字及其包裝型別之間時有效。因此，先前撰寫的宣告：

type Foo = bits : uint32 {...

現在會寫為：

type Foo = bits of uint32 {...

將限制清單括在方括號中

限制清單現在會以方括號 (而非尖括號) 括住。因此，先前撰寫的型別宣告：

vector<vector<zx.handle:<VMO,zx.READ,optional>>>

現在寫成

vector<vector<zx.handle:[VMO,zx.READ,optional]>>

實作

這項提案將做為更廣泛的 RFC-0050 FIDL 語法轉換的一部分實作。以「新」語法編寫的所有 FIDL 檔案，都應符合本 RFC 中列出的變更，而正式的 FIDL 文法也會在 RFC-0050 的其餘部分發布時，一併更新以反映其設計。

效能

這些語法變更不太可能影響成效。

安全性考量

這些語法變更不太可能對安全性造成影響。

隱私權注意事項

這些語法異動不太可能影響隱私權。

測試

這些語法變更將在涵蓋 RFC-0050 的更廣泛測試套件中進行測試。

說明文件

所有相關說明文件和範例都會更新，以納入新的語法，這是 RFC-0050 說明文件更新的一部分。

缺點、替代方案和未知事項

「bits」和「enum」版面配置的新分隔線

我們考慮過新 bits/enum 語法的替代公式，其中包裝型別會以角括號括住：type E = enum<int32> {...。我們認為，這種參數化型別語法的使用方式，與 vector 和 array 的現有意義不太一致：enum<int32> 是線路上的實際 int32 (也就是包裝型別和線路型別相同)，而 vector<int32> 的內部型別則說明某些包含線路容器的酬載 (也就是包裝型別只是完整線路型別的一部分)。此外，如果 vector<int32> 是有效的型別建構函式，則 bits 和 bits<int32> 都不是。如果在此情況下使用尖括號語法，會以細微但令人困惑的方式，造成語意過載。

將限制清單括在方括號中

建議的限制條件語法有兩種替代方案：保留目前的尖括號標記，或完全移除括號。這兩者都難以讓讀者以視覺方式剖析：vector<vector<zx.handle:<VMO,zx.READ,optional>>> 包含許多巢狀角括號和不同類型的引數清單，而 vector<vector<zx.handle:VMO,zx.READ,optional>> 則難以辨識版面配置的終止位置和限制的開始位置。

既有技術和參考資料

本 RFC 是 RFC-0050：語法修訂中定義語法的演進版本。