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

拒绝理由

在起草和共享此提案时，我们达成了一致共识，即一次性考虑语法更改，而不是一次更改一个（另请参阅 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 影响，从而改善了人体工学。

文档和示例

至少：

• 语言规范
• 语法
• 使用结构体的示例

向后兼容性

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