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

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

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

修改此 RFC

修改 RFC 元数据

遭拒的理由

在拟定此方案并加以社交时，人们达成一致意见，即需要一次更改所有语法，而不是一次更改一个（另请参阅 RFC-0039）。我们还希望由一人成为语法控制者，而不是由委员会来承担风险设计。

最终，此方案已被 RFC-0050 取代，而 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 影响，从而改善工效学设计。

文档和示例

至少：

向后兼容性

这不是源代码级别的向后兼容性。