RFC-0021：方法的软转换添加和移除

RFC-0021：为方法添加和移除添加了软过渡
状态已接受
区域
  • FIDL
说明

我们建议声明一个新属性，以便代码能够构建，无论方法是否已实现。
作者
提交日期（年-月-日）2018-10-31
审核日期（年-月-日）2018-11-01

修改此 RFC

修改 RFC 元数据

摘要

我们建议声明一个新属性，以便代码能够构建，无论方法是否已实现。

设计初衷

自从将 Fuchsia 树移至全局集成花模型以来，重大更改变得非常困难。这是因为，为了在绑定中实现 FIDL 接口，开发者必须在其具体实现中实现 FIDL 接口中定义的一组方法。这意味着，如果在一个花瓣中向接口添加或从中移除方法，全局集成将会失败。

设计

我们应声明一个新属性 [Transitional="description"]，该属性指示绑定生成无论方法是否已实现都能成功构建的代码。

调用过渡方法是实现定义的 - 它可能按文档所述工作，可能永远不会完成，甚至可能导致调用方或被调用方崩溃。不得干扰其他方法的运行，并且必须能够实现该方法。 FIDL 前端编译器根本不需要更改，只需要更改语言绑定。

C

  • 在 C 绑定中未能实现方法不是 build-time 错误，因此此处无需执行任何操作。

C++

  • 不要将方法声明为纯虚函数，而是声明为具有具体基本实现（仅打印错误）的函数。

Dart

  • 不要声明没有正文的方法，而是声明具有正文的方法，该正文会返回失败的 Future 或抛出异常（具体取决于绑定样式）。

Go

  • 过渡方法可以在新引入的结构“InterfaceStubBase”上具有默认实现，该结构可以嵌入到实际的实现结构中，以提供向前/向后兼容性。

Rust

  • 待定

实施策略

一旦我们有了长期演进方法，就会从 FIDL 中移除此功能。

文档和示例

向后兼容性

请参阅下文中的缺点。

性能

不使用时不会影响性能。 通过使用动态调度来调用 [Transitional] 方法，而不是使用更直接的调用策略，可能会增加间接性。

安全

没有影响，过渡方法会快速失败。

测试

在 before/during/after 库上进行代码生成，以模拟使用 [Transitional] 属性添加或移除方法和事件，并确保编译成功。

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

这无法为 FIDL 接口的长期发展提供前进方向。 它不支持重命名方法或更改方法签名，但可以作为多阶段流程的一部分用于实现这些目的。 它无法解决向联合添加变体的问题。

在先技术和参考资料

不适用