RFC-0039：类型优先

RFC-0039：类型排在第二
状态已拒绝
领域
  • FIDL
说明

我们提议允许对结构体、xunion 和表进行内嵌声明；反转字段名称（或参数和返回名称）在类型中的显示顺序，特别是让类型显示在名称之后。
作者
提交日期（年-月-日）2019-03-07

修改此 RFC

修改 RFC 元数据

“你会想要爱上它”

遭拒原因

此提案在起草并传达给社会后就得到了广泛认可， 一次考虑所有语法更改，而不是一次更改一项（另请参阅 RFC-0038）。 我们还希望有一个人担任语法仲裁者，而不是承担设计风险 由委员会决定。

此提案最终被 符合的 RFC-0050 这两种情况。

摘要

我们建议：

  • 允许以内嵌方式声明结构体、联合和表；
  • 反转字段名称（或参数/返回值）的显示顺序： 与类型相关，具体来说是将类型显示在名称之后。

（我们没有引入匿名声明，因为很可能需要 改进了绑定支持，以确保良好的工效学设计。）

设计初衷

快速：

  • 我们开始看到更多模式，其中各种声明组合 描述“一条概念性消息”是日常安排。例如： <ph type="x-smartling-placeholder">
      </ph>
    • 容器结构体，其最后一个字段是要在 扩展程序的大门
    • 容器联合，其中变体是具有灵活性的表。
    • 容器表，其中字段按结构体分组，序数松散 与“版本号”一致。
  • 此外，支持空结构体、联合和表 （通过布局）构建代数数据类型支持的低层级内容 立场，而不是绑定）。
  • 所有这些用例都在促使我们允许使用内联声明。
  • 使用内联声明，首先可以更轻松地读取字段名称，然后 类型描述，可以跨多个行。请参见下面的示例。

设计

请参见以下示例：

  • 简单的结构体或表：

    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 的含义传达给开发者，可改善工效学设计 。

文档和示例

至少：

向后兼容性

这并非源代码级向后兼容。