RFC-0038：将布局与约束条件分离

RFC-0038：将布局与约束条件分离
状态已拒绝
领域
  • FIDL
说明

我们提议更改语法，以便传达布局与约束条件之间的差异。
作者
提交日期（年-月-日）2019-03-07

修改此 RFC

修改 RFC 元数据

遭拒原因

此提案在起草并传达给社会后就得到了广泛认可， 一次考虑所有语法更改，而不是一次更改一项（另请参阅 RFC-0039）。我们还 希望一个人担任语法仲裁者，而不是冒险 委员会。

此提案最终被 符合的 RFC-0050 这两种情况。

摘要

我们提议更改语法，以便传达 限制条件。

设计初衷

布局与约束条件

快速：

  • 如果两种类型的布局不同，则无法进行软转场 反之亦然（至少不太容易）。
  • 布局描述了字节的布局方式以及解释方式。
  • 类型的限制是编码/解码期间完成的验证步骤。
  • 限制条件可能会发生变化，只要撰写者比 它们是兼容的

适用于不同内容的相同语法

具有不同布局的类型以及具有相同布局的类型（但 都是一样的。

相同布局：

  • vector<T>:6或vector<T>:10
  • T?，其中 T 为 union、vector 或 string
  • handle、handle<vmo> 或 handle<channel>

不同的布局：

  • array<T>:6与 array<T>:10
  • S?，其中 S 是 struct

设计

在语法上保持一致

layout:constraint

对于类型，即控制布局的所有内容都位于冒号之前， 控件限制位于冒号后面。

建议的更改：

    array<T>:N    becomes            array<T, N>

    S?            becomes            box<S>:nullable       (S is a struct)

    T?            becomes            T:nullable            (T is a vector, or union)

    string        is an alias for    vector<uint8>:utf8

    handle<K>     becomes            handle:K

注意：

  • 并非所有限制条件对所有类型都有意义，例如，它并不是 可以将 struct 标记为可为 null。
  • 并非所有内容都可以装箱，最初只有结构体可以（目标是 语法，而不是引入更多具有可选性的方法）。

工效学设计

此方案将 ABI 的含义传达给开发者，可改善工效学设计 。

文档和示例

至少：

向后兼容性

这并非源代码级向后兼容。