| RFC-0088：RFC-0050 更新：FIDL 位、枚举和约束语法 | |
|---|---|
| 状态 | 已拒绝 |
| 领域 |
|
| 说明 | 指定对 FTP-050 定义的新 FIDL 语法的两项增量改进。 |
| 问题 | |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2021-02-18 |
| 审核日期（年-月-日） | 2021-04-07 |
遭拒的理由
此方案被拒绝，因为建议的更改对现有状态而言都没有明显的改进。
另见：
bits 和 enum 布局的新分隔符
此 RFC 最初是因为观察到的以下观察结果而引发：RFC-0050：语法修订 (RFC-0050: Syntax Revamp) 指出，冒号旨在分隔布局和约束条件，但它们在 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 属性语法 (RFC-0086: Updates to FTP-050: FIDL Attributes Syntax) 中，FIDL 语法中不再使用方括号。如果用尖括号来描述已经足够清楚的语法，那种“刻录”这种括号类型（我们只能找到四种：圆角、弯曲、尖括号和方括号）是非常浪费的。这只是一个很小的更改，其现有状态在实践中不太可能引起很多混淆。
这只是一个非常小的更改，其现有状态在实践中不太可能引起很多混淆。
总结
本文档提出了对 RFC-0050：语法修订中所述的语法的两项次要更新。具体而言：
bits和enum布局的封装类型定义不再需要使用英文冒号来分隔布局说明符和封装类型。相反，新引入的of关键字将用作分隔符。- 限制条件列表现在用方括号而不是尖括号括起来。
设计初衷
由 RFC-0050 定义的新语法正在实现中，这是对该标准进行最终更新的好机会。最好通过一次“一刀切”的方式进行大规模语法迁移，而不是将更改分散到多个项目中（RFC-0038：将布局与约束条件分离和 RFC-0039：类型来二次由于该原因遭到了拒绝，这导致了更大规模的 RFC-0 崩溃）。因此，最好将任何最终的语法调整都纳入到更广泛的 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：语法修订中定义的语法的演变。