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：语法改进中定义的语法的演变。