| RFC-0088：RFC-0050 更新：FIDL 位元、列舉和限制語法 | |
|---|---|
| 狀態 | 已遭拒 |
| 領域 |
|
| 說明 | 為 FTP-050 定義的新 FIDL 語法指定兩個漸進式改善項目。 |
| 問題 | |
| 毛皮變化 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2021-02-18 |
| 審查日期 (年-月-日) | 2021-04-07 |
拒絕原因
這些提案由於這些變更提案不清楚，因此遭到拒絕 明顯改善了事務現狀
另請參閱：
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 影響。
總而言之，多數使用者很快就會發現
這兩個情況是 layout : constraints 規則的特殊例外狀況
一文中所述的 RFC-0050：語法修訂部分。
以方括號括住限制清單
拒絕這項變更的原因有兩個：
- 語言會設定參數以特定角度顯示 括號，不論其參數類型 (版面配置或限制) 為何 使用方括號會中斷這個期望。
- 使用 RFC-0086：FTP-050 更新：FIDL 屬性語法 FIDL 語法中不再使用方括號。會是 不利於「燒傷」這種括號類型 (我們只提供四種： 四捨五入、三角、角度和正方形) 是用於描述已經 以帶有角括號的方式清晰可辨我們只是小幅調整 但是現有狀態不太可能在實務上造成太大混淆。
只是相當小的改變，現有狀態不太可能 避免在實務上產生混淆
摘要
針對 RFC-0050：語法修訂。具體違規事項如下：
bits和enum版面配置的包裝類型定義不再需要 使用冒號分隔版面配置指定碼和包裝的類型。相反地 新導入的of關鍵字會用做分隔符。- 限制清單現在會以方括號 (而非角括號) 括住。
提振精神
正在實作 RFC-0050 定義的新語法， 讓您有機會對這項標準進行最終更新是 較適合將大型語法遷移當做單一「單一項目」努力 而不是將變更分散到許多專案中 (RFC-0038：區隔 Layout from Constraints 和 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 語法轉換。所有以「new」記載的 FIDL 檔案語法將 以符合 RFC 的 文法將會隨之更新，反映其他方面的設計 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。