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 含义，从而改进了工效学设计。

文档和示例

至少：

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

向后兼容性

此提案不具备源代码级向后兼容性。