RFC-0039：类型优先

RFC-0039：类型次之
状态已拒绝
区域
  • FIDL
说明

我们建议允许内联声明结构、xunion 和表；翻转字段名称（或实参和返回值名称）相对于类型的显示顺序，具体来说是将类型显示在名称之后。
作者
提交日期（年-月-日）2019-03-07

修改此 RFC

修改 RFC 元数据

“您一定会爱上它”

拒绝理由

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

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

摘要

我们建议：

  • 允许内联声明结构体、联合和表；
  • 翻转字段名称（或实参/返回值名称）相对于类型的显示顺序，具体来说就是让类型显示在名称之后。

（我们不会引入匿名声明，因为我们可能需要改进绑定支持，以确保人体工程学效果良好。）

设计初衷

快速：

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

设计

请参见以下示例：

  • 简单结构或表格：

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

文档和示例

至少：

向后兼容性

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