RFC-0039：类型优先

RFC-0039：类型位于第二位
状态已拒绝
区域
  • FIDL
说明

我们提议允许内嵌声明结构体、xunion 和表；将字段名称（或参数和返回名称）与类型的显示顺序颠倒过来，具体而言，将类型显示在名称后面。
作者
提交日期（年-月-日）2019-03-07

修改此 RFC

修改 RFC 元数据

“You're Go-ing to love it”

拒绝理由

在起草和共享此提案时，我们达成了一致共识，即一次性考虑语法更改，而不是一次更改一个（另请参阅 RFC-0038）。我们还希望由一个人来决定语法，而不是冒着由委员会设计的风险。

最终，此提案被 RFC-0050 取代，后者满足了所需的两个条件。

摘要

我们提议：

  • 允许内嵌声明结构体、联合体和表；
  • 将字段名称（或参数/返回名称）与类型的显示顺序颠倒过来，具体而言，使类型显示在名称后面。

（我们没有引入匿名声明，因为我们可能希望改进绑定支持，以确保良好的人体工学体验。）

设计初衷

快速：

  • 我们开始发现越来越多的模式，其中组合使用各种声明来描述“一个概念消息”是常规做法。例如：
    • 容器结构体，其最后一个字段是一个表（最初为空），以便为扩展程序留出余地。
    • 容器联合，其中变体是表，以实现灵活性。
    • 容器表，其中字段按结构体分组，而序数与“版本号”大致匹配。
  • 此外，对空结构体、联合体和表的支持提供了构建代数数据类型支持的低级部分（从布局角度，而不是绑定角度）。
  • 所有这些用例都促使我们允许内嵌声明。
  • 使用内嵌声明时，您可以先读取字段名称，然后再读取类型说明（可以跨多行）。请参见下面的示例。

设计

请参见以下示例：

  • 简单的结构体或表格：

    struct Name {
    field int32;
};

table Name {
    1: field int32;
};

  • 协议：

    protocol Name {
    Method(arg int32) -> (ret int32);
};

  • 带有扩展的结构体：

    struct Name {
    field1 T1;
    field2 T2;
    ...;
    ext table NameExt {};
};

  • 联合变体：

    union Name {
    variant1 table NameVariant1 {
        ...
    };
    variant2 table NameVariant2 {
        ...
    };
    ...
};

  • 按版本对字段进行分组：

    table Name {
    1: v1 struct NameGroupV1 {
        ...
    };
    2: v2 struct NameGroupV2 {
        ...
    };
    ...
};

注意：

  • 在作用域方面，虽然我们会将所有声明名称视为顶级名称（因此会按库强制执行唯一性），但我们不允许引用内嵌声明，即只能单次使用。

工效学设计

此提案通过语法向开发者传达 ABI 影响，从而改善了人体工学。

文档和示例

至少：

向后兼容性

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