RFC-0045：零大小的空结构体

拒绝理由

此 RFC 已被其作者拒绝，原因是存在优先级更高的工作，且影响较小。 如果这些想法日后被证明具有更高的影响力，我们可以稍后重新考虑。

因此，部分内容不完整。

摘要

RFC-0056（“空结构体”）通过允许定义空结构体来改进语言的人体工程学。 空结构体不包含任何内容，但目前在有线格式中占用一个字节，以便与所有 FIDL 语言实现兼容。这会占用不必要的空间，而且由于 FIDL 在许多上下文中的 8 字节对齐，这种情况通常会变得更糟。

此 RFC 基于 RFC-0056，通过增强空结构体来使其在网络上传输时占用零字节。

设计初衷

RFC-0056 确定了空结构体的应用场景：

• 计划的未来用途，
• 作为并集中的一个选项，
• 作为命令模式的一部分，

除了携带零信息的对象占用非零数量的线路空间这一普遍的不雅之处外，空结构的有效实现对于潜在的未来 FIDL 工作（例如代数数据类型或泛型）可能非常重要。

大小为 1 的空结构体设计还会让所有其他 FIDL 目标语言付出 C++ 特有的代价（有关详情，请参阅下方的设计）。其他语言通常可以用零字节表示空结构体。

设计

两种设计：一种选择。我们必须做出选择。

我更喜欢设计 1，其中我们使用零长度数组来表示空结构。 这样一来，用户就不会感到那么意外，而且在所有使用情形下，这种行为都是一致的。 缺点是我们需要 C 扩展，这可能无法接受。

设计 2 可以实现，但当空结构体用作 FIDL 方法的形参时，人体工程学方面可能会出现令人惊讶的问题。希望您能提供一些想法和反馈。

如果编译器支持零长度数组，我们还可以假设采用设计 1；如果不支持，则假设采用设计 2。我有点喜欢这样。

设计 1：零长度数组

此 RFC 建议使用零长度数组来表示空结构体。这是 FIDL 的目标 C 和 C++ 编译器支持的常用扩展。

对于 C 和 C++，简化后的示例看起来类似：

// FIDL: struct Empty {};

// define a zero-length array type
typedef int FIDLEmptyStructInternal[0];

typedef struct {
  FIDLEmptyStructInternal reserved;
} Empty;

上述代码段会针对 C 和 C++ 断言为 sizeof(Empty) == 0。实际上，为绑定生成的代码应针对 C 和 C++ 关闭各种警告¹；GitHub Gist 显示了更完整的 C 和 C++ 绑定生成示例。

设计 2：完全省略发出空结构

FIDL 结构体必须转换为 C 和 C++ 中的等效结构体。空结构体是一种特殊情况，因为 C 和 C++ 在处理空结构体的方式上有所不同：

• C 将空结构体的大小留作未定义²。许多编译器（例如，gcc 和 clang），因此将空结构体定义为零大小。
• C++ 将空结构体定义为具有 1 的大小。大多数编译器都采用“空基类”优化，以便在特定情况下将它们优化为 0。

作为一种解决方法，RFC-0056 提议生成一个具有单个 uint8 成员的结构体来表示空结构体，这在 C 和 C++ 中是一致的。

空结构体会在以下三种不同的上下文中出现：

• 在包含结构体中，
• 在包含的并集或表格内，或者
• 作为 FIDL 接口方法的参数，成为“顶级”结构体。

这三种上下文可以单独处理。

在包含结构体中

包含结构体内的空结构体可以省略空结构体的成员。 例如，以下 FIDL 结构：

// FIDL
struct FooOptions {
    // There is currently no information here but
    // we have preserved the plumbing for now.
};

struct Foo {
    uint32 before;
    FooOptions options;
    uint32 after;
};

只需在 C/C++ 绑定中省略生成“FooOptions”空结构体成员即可：

// generated C or C++ code
struct Foo {
    uint32_t before;
    // "FooOptions options" is missing here
    uint32_t after;
};

序列化的 FIDL 有线格式随后会与 C/C++ 内存布局兼容，并且可以直接转换为/从任一格式转换。

由于空结构体不包含任何信息，因此无法访问 .options 成员的影响不大。如果该结构体后来更改为非空，则包含结构体可以以源代码兼容的方式发出之前为空的结构体成员 options ³。

用户可能希望执行的一项合理操作是获取空结构的地址，即 &(foo.options)，但此更改后将无法再执行此操作。 我们认为，为了实现一致的跨语言零大小空结构体，这种权衡是可以接受的。

TODO(apang)：Go、Rust、Dart。

在包含表或并集中

表或（静态或可扩展）联合具有指示表/联合携带的信息的序号（“标记”）。 在这种情况下，空结构体“携带信息”是指它的存在本身就代表信息，即使空结构体本身不携带任何信息。

因此，表或联合仍会发出序号，以便客户端代码可以检查该序号，从而确定表/联合中包含哪些信息。不过，空结构本身将无法访问。 例如，空结构的联合：

// FIDL
struct Option1 {};
struct Option2 {};
union {
    // an "empty" union!
    Option1 o1;
    Option2 o2;
};

仍会：

1. 具有明确定义的内存布局，其中将包含单个 uint32 枚举标记。
2. 发出表示序号和相应访问器方法的枚举，以便客户端代码可以创建和检查此类联合。

TODO(apang)：包含 C/C++ 绑定的示例。

表格类似：空结构体作为表格字段的存在表示信息。对于联合，我们采用相同的方法，即为序号和客户端代码发出枚举，但省略对空结构的访问，这种方法也可用于表。

TODO(apang)：Go、Rust、Dart。

作为 FIDL 方法参数

在现有使用场景中，空结构体用作 FIDL 方法参数，例如在 fuchsia.ui.viewsv1 中：

interface ViewContainerListener {
    // |ViewInfo| is an empty struct
    OnChildAttached(uint32 child_key, ViewInfo child_view_info) -> ();
};

struct ViewInfo {};

任何为空结构体的方法参数都可以：

1. 从方法签名中省略（推荐），
2. 在 C 或 C++ 中规范化为单个空结构体 singleton 类型（例如 fidl::EmptyStruct），该类型不直接映射到零字节线格式，或者
3. 按原样发出，语言表示形式不会直接编码/解码为有线格式。

变更

• 无需更改 FIDL 源语言。
• FIDL 有线格式和文档将发生更改，以便空结构在有线上占用 0 字节，而不是 1 字节。
• fidlc 无需进行任何更改。
• 每个语言后端（C、C++、Rust、Go、Dart）都需要更新，以反映本部分讨论的绑定更改。这应作为硬过渡来完成，以便保留跨层 ABI 兼容性。

实施策略

实现将类似于 RFC-0056，并且需要拆分为多个 CL：

• 用于更新所有语言的生成绑定的 CL，但不更新跨语言兼容性测试。
• 硬过渡集成 CL，以确保滚动更新成功。
• 更新了跨语言功能。
• 更新。

对于此 RFC，无需更改 FIDL 源语言。

缺点、替代方案和未知因素

请注意：

• 在 C 和 C++ 中保持一致
• 这两种语言具有不同的尺寸实现
• C++ 在概念上要求
• 零长度数组
• C++ [[no_unique_address]]

在先技术和参考资料

https://herbsutter.com/2009/09/02/when-is-a-zero-length-array-okay/