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

拒絕理由

這項提案遭到拒絕，因為所提變更並未明顯改善現況。

另請參閱：

• RFC-0050：FIDL 語法重整
• RFC-0086：更新 RFC-0050：FDil 屬性語法
• RFC-0087：更新 RFC-0050：FDil 方法參數語法

bits 和 enum 版面配置的新分隔符

這個 RFC 最初的動機是觀察到 RFC-0050：語法改良指出冒號用於分隔版面配置和限制，但在 bits 和 enum 宣告中使用冒號來標示包裝型別，就會違反這項規則。最終，我們認為這項不一致性並未造成足夠的歧義，因此不應為了這兩種用途而單獨設計新語法，以便移除冒號。

提出的替代方案都沒有比冒號更適合。我們考慮了以下幾個選項：

• 我們認為直接移除冒號會造成混淆，因此第二種型別會修改 (或「模板化」) bits 或 enum 宣告。應有表示這種情況的語法。
• 將已包裝的型別放在括號中 (例如 bits<uint32> {...) 也遭到拒絕，因為這與 FIDL 語言中其他角括號的用法不一致。目前的尖括號旨在包含版面配置參數，例如內建 vector 版面配置由 vector<TYPE> 設定參數，內建 array 版面配置由 array<TYPE, SIZE> 設定參數。不過，將包裝的類型放在方括號中，會更類似於產生版面配置定義的範本，例如 (目前不支援) struct<K,V>{...}。以這種方式混用角度括號的含義，被判定為太過微妙且容易混淆。
• 最後，我們考慮將冒號替換為新關鍵字 of。這也被視為不理想的做法，因為為了因應兩個非常輕微的邊緣案例，而引入認知額外負擔 of 讓 FIDL 作者學習新關鍵字，這是不利的交易。此外，這會偏離目前使用的語法樣式，後者更偏向 C 語言風格，而非 ALGOL 風格。

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

將限制清單括入方括號內

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

• 無論參數為何種參數 (版面配置或限制)，語言都會預期參數會出現在斜線括號內。使用方括號會違反這項預期。
• 根據 RFC-0086：對 FTP-050 的更新：FIDL 屬性語法，FIDL 語法不再使用方括號。使用這個括號類型 (我們可用的四種括號之一：圓括號、大括號、角括號和方括號) 來描述已經使用角括號清楚表示的語法，會造成浪費。這只是非常微小的變更，現有狀態在實際操作中不太可能造成混淆。

這只是非常微小的變更，現有狀態在實際操作中不太可能造成太多混淆。

摘要

本文件針對 RFC-0050：語法重整一文中所述的語法，提出兩項次要更新。具體違規事項如下：

• bits 和 enum 版面配置的包裝型別定義不再需要使用冒號來區隔版面配置指定碼和包裝型別。而是使用新推出的 of 關鍵字做為分隔符。
• 限制清單現在會以方括號而非斜線括號包裝。

提振精神

RFC-0050 定義的新語法導入作業正在進行中，這正是最終更新該標準的絕佳時機。建議一次完成大規模的語法遷移作業，而非分散在多個專案中進行 (RFC-0038：將版面配置與限制條件分開和 RFC-0039：Types Come Second 就是基於這個原因而遭到拒絕，導致後續的 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：語法改良 中定義的語法演進版本。