RFC-0088：RFC-0050 更新：FIDL 位、枚举和约束语法

RFC-0088：对 RFC-0050 的更新：FIDL 位、枚举和约束语法
状态已拒绝
区域
  • FIDL
说明

指定对 FTP-050 定义的新 FIDL 语法的两项增量改进。
问题
Gerrit 更改
作者
审核人
提交日期（年-月-日）2021-02-18
审核日期（年-月-日）2021-04-07

修改此 RFC

修改 RFC 元数据

拒绝理由

此提案被拒绝，原因是所提出的两项变更均未对现有情况带来明显改进。

另见：

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：类型居于第二位正是基于此原因而被拒绝，这导致了更大的改版，最终促成了 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：语法改版中定义的语法的改进。