| RFC-0088：RFC-0050 更新：FIDL 位、枚举和约束语法 | |
|---|---|
| 状态 | 已拒绝 |
| 领域 |
|
| 说明 | 指定对 FTP-050 定义的新 FIDL 语法的两项增量改进。 |
| 问题 | |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2021-02-18 |
| 审核日期（年-月-日） | 2021-04-07 |
遭拒原因
由于两项更改建议均不明确，此提案已被拒绝 并且比现有状况有明显改进。
另见：
bits 和 enum 布局的新分隔符
创建此 RFC 最初源于观察到，RFC-0050: Syntax
Revamp 指出英文冒号旨在分隔布局和
约束条件，但是它们用于划分 bits 中的封装类型，
enum 声明就破坏了此规则。最终，这种不一致性被认为是
不足以说明发明新语法的合理性
只为这两个用例移除冒号。
所有提议的替代方案都没有立即优于冒号。部分 考虑过的解决方案：
- 直接移除冒号会被认为会造成混淆 - 第二种类型
或“模板”
bits或enum声明。其中应该有 语法说明情况确实如此。 - 将封装后的类型放入方括号中（例如
bits<uint32> {...）也是 因为这与之前在 Google 文档中使用尖括号的 FIDL 语言。如今使用的尖括号是用来 例如，使用内置vector布局 由vector<TYPE>参数化，并且内置array布局 由array<TYPE, SIZE>参数化。但将封装的类型放在方括号中 更类似于生成布局定义的模板， （目前不支持）struct<K,V>{...}。混搭“角度”的含义 认为以这种方式使用括号过于隐晦和含糊。 - 最后，考虑使用新关键字
of替换冒号。 这也被认为不尽如人意，因为这会增加认知开销，of- 供 FIDL 作者学习的新关键字，以同时满足两个条件 非常微小的极端情况是糟糕的交易。此外，这也偏离了 语法样式，更倾向于类似于 C 语言的内容， 而不是由 ALGOL 影响的模型。
最终，大多数用户可能很快就会发现
这两种情况是 layout : constraints 规则的一个特殊例外情况
RFC-0050：语法改进中所述。
将限制条件列表封装在方括号中
拒绝此更改的原因有两个：
- 该语言设定了一种预期，即参数应在 Angular 和 括号，无论它们属于何种参数（布局或约束条件） 情况。使用方括号会打破这种预期。
- 在 RFC-0086: Updates to FTP-050: FIDL Attributes Syntax 中， FIDL 语法中不再使用方括号。我们原本可以 浪费时间括号类型（我们仅提供四种类型之一： 圆角、卷曲、斜角和方形）来描述已经存在的语法， 用尖括号表示足够清晰。这只是一个很小的变化 其现有状态不太可能在实践中造成很多混淆。
这只是一个非常小的变化，其现有状态不太可能导致 在实际操作中会产生很多混淆
摘要
本文档提议对 RFC-0050：语法改进。具体而言：
bits和enum布局的封装类型定义不再需要 用于分隔布局说明符和封装类型的英文冒号。相反， 新引入的of关键字用作分隔符。- 限制条件列表现在用方括号括起来，而不是用尖括号括起来。
设计初衷
RFC-0050 定义的新语法还在实施中， 这是对该标准进行最终更新的好机会时间是 最好一次性完成大规模语法迁移努力， 而不是将更改四处散布到多个项目中（RFC-0038：分离 Constraints 布局和 RFC-0039: Types Come Second 并因此而遭拒登，这也随之导致了更大的改造，最终 RFC-0050）。因此，最好将任何最终语法 调整到更广泛的 RFC-0050 迁移工作。
bits 和 enum 布局的新分隔符
RFC-0050 指定格式为 layout:constraints；也就是说，FIDL
文件读取者应该知道，类型中冒号左侧的所有内容
声明会影响字节在传输中的组织方式，而
是对类型可能包含的值运行时强制执行的约束条件。
目前，这种约定有一个例外情况：bits/enums 声明，
这会使布局影响冒号右侧的信息。这个
导致 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 文件，语法为 以及正式的 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：语法 改版。