RFC-0021：添加和移除方法的软转换
状态	已接受
领域	FIDL
说明	我们提议声明一个允许构建代码的新属性，而无论方法是否实现。
作者	ianloic@google.com
提交日期（年-月-日）	2018-10-31
审核日期（年-月-日）	2018-11-01

总结

我们提议声明一个新属性，让无论方法是否已实现，都允许构建代码。

设计初衷

自从将 Fuchsia 树迁移到全局集成的花卉模型以来，硬性更改变得...很困难。这是因为，如需在绑定中实现 FIDL 接口，开发者必须在其具体实现中准确实现 FIDL 接口中定义的一组方法。这意味着，如果一个方法在接口中添加或移除了一个方法，则全局集成将会失败。

设计

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

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

C

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

C++

• 不要将方法声明为纯虚函数，而是使用只是输出错误的具体基本实现来声明这些方法。

Dart

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

Go

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

Rust

• 待定

实施策略

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

文档和示例

向后兼容性

请参阅下文的缺点。

性能

不使用时不会影响性能。 通过对 [Transitional] 方法使用动态调度（而非更直接的调用策略），可能会产生额外的间接调用。

安全性

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

测试

在之前/期间/之后库生成代码，以使用 [Transitional] 属性模拟添加或移除方法和事件，并确保编译成功。

缺点、替代方案和未知情况

不过，这并没有为 FIDL 接口的长期发展提供前进的道路。 不提供重命名方法或更改方法的签名，但您可以将其用作多阶段流程的一部分。它没有解决将变体添加到联合的问题。

早期技术和参考资料

不适用