RFC-0039：类型优先

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

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

修改此 RFC

修改 RFC 元数据

“您会爱上它的”

遭拒的理由

在拟定此方案并加以社交时，人们达成一致意见，即需要一次更改所有语法，而不是一次更改一个（另请参阅 RFC-0038）。 我们还希望由一个人来主导语法规则，而不是由委员会来冒险设计。

最终，此方案已被 RFC-0050 取代，而 RFC-0050 同时满足了这两种情况。

总结

我们提议：

  • 允许结构体、联合和表的内嵌声明；
  • 按类型切换字段名称（或参数/返回名称）的显示顺序，特别是让类型显示在名称后面。

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

设计初衷

迅速：

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

设计

请参见以下示例：

  • 简单的结构体或表：

    struct Name {
    field int32;
};

table Name {
    1: field int32;
};

  • 协议：

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

  • 带有扩展的 Struct：

    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 影响，从而改善工效学设计。

文档和示例

至少：

向后兼容性

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