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

拒绝理由

在起草并公开此提案时，大家一致认为应一次性考虑语法变更，而不是一次考虑一个（另请参阅 RFC-0039）。我们还希望由一个人来决定语法，而不是冒着设计委员会的风险。

最终，RFC-0050 使此提案过时，该 RFC 满足了所寻求的两个条件。

摘要

我们建议更改语法，以传达来自约束的布局之间的差异。

设计初衷

布局与约束

快速：

• 如果两种类型的布局不同，则无法从一种类型软过渡到另一种类型，反之亦然（至少不容易）。
• 布局描述的是字节的排列方式，而不是字节的解读方式。
• 类型的约束是在编码/解码期间完成的验证步骤。
• 约束条件可能会不断变化，只要写入者的约束条件比读取者多，一切就都是兼容的。

语法相同，但含义不同

布局不同的类型和布局相同的类型（但限制不同）看起来相似。

相同布局：

• 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 含义，从而提高人体工程学效果。

文档和示例

至少：

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

向后兼容性

这不属于源代码级向后兼容。