| RFC-0088：RFC-0050 更新：FIDL 位元、列舉和限制語法 | |
|---|---|
| 狀態 | 已遭拒 |
| 區域 |
|
| 說明 | 針對 FTP-050 定義的新 FIDL 語法指定兩項增量改善。 |
| 問題 | |
| 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年/月) | 2021-02-18 |
| 審查日期 (年/月) | 2021-04-07 |
拒絕原因
由於提議的變更都無法清楚且明顯地改善目前的事務狀態，因此這個提案遭到拒絕。
另請參閱：
新增 bits 和 enum 版面配置的分隔符
這個 RFC 最初的考量是 RFC-0050: Syntax
Revamp 狀態的觀察來了，冒號是用來分隔版面配置和限制，但使用 bits 和 enum 宣告來分解包裝類型的做法不符合這項規則。最終，這種資料不一致並不夠明確，因為在開發新語法時，僅僅針對這兩種用途移除冒號。
所有提議的替代項目都立即比冒號來得好。考量到的選項：
- 我們認為，只移除半形冒號會讓使用者感到困惑，第二種類型會修改 (或稱「範本」)，
bits或enum宣告。都應該有語法指出這種情形。 - 此外，也拒絕將包裝類型放在方括號中 (例如
bits<uint32> {...)，因為此類型與 FIDL 語言中其他使用角括號的方式不一致。目前站立的方角括號旨在包含版面配置參數，如同vector<TYPE>將內建vector版面配置參數化，而內建array版面配置由array<TYPE, SIZE>參數處理的情況。但將包裝的類型放在括號中，與產生版面配置定義的範本類似，例如 (目前不支援的)struct<K,V>{...}。這種將角括號的意義混合在一起，被視為過於細微且令人困惑。 - 最後，系統會將冒號替換成新關鍵字
of即可。這也算令人不悅，因為為 FIDL 作者引入認知負擔of新關鍵字，為滿足兩個非常小的極端案件發展而提供學習新關鍵字，這就是不好的交易。此外，這與以往使用的語法樣式不同，後者傾向採用類似 C 的口味，而非受到 ALGOL 影響。
最後，大多數使用者可能會快速發現，這兩個情況是 RFC-0050：語法修訂中描述的 layout : constraints 規則的特殊例外情況。
以方括號括住限制清單
拒絕這項變更的原因有兩個：
- 語言會期望參數出現在角括號內，無論其屬於哪種參數 (版面配置或限制)。使用方括號有可能會違反這項期望。
- 使用 RFC-0086：FTP-050: FIDL 屬性語法時，FIDL 語法中不再使用方括號。我們要「燃燒」這個方括號類型 (我們只有四種括號類型之一：圓、大、角和正方形) 描述的語法原本就足夠清楚的圓角括號。這只是相當微小的變化 因為現有狀態不太可能在實務上造成混淆
這只是相當小的改變，現有的狀態不太可能在實務中造成太大的混淆。
摘要
本文件針對 RFC-0050：語法修訂 中所述的語法提出兩項次要更新。具體違規事項如下：
bits和enum版面配置的包裝類型定義不再需要使用冒號分隔版面配置指定碼和包裝類型。因此，系統會使用新導入的of關鍵字做為分隔符。- 限制清單現在是以方括號 (而非角度和方括號) 包住。
提振精神
正持續實作 RFC-0050 定義的新語法，您將有機會對該標準進行最終更新。我們建議將大型語法遷移作業視為單一「失敗一次」工作，而不是將變更集中在許多專案上。(RFC-0038：將版面配置與限制分開，RFC-0039：類型強迫症)，導致 RFC 重覆，導致超過 50% 的破壞力徹底降低。因此，建議您將最終語法調整到更廣泛的 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：語法 Revamp 定義的語法進化。