| RFC-0065：无可选字符串或向量 | |
|---|---|
| 状态 | 已拒绝 |
| 区域 |
|
| 说明 | 从 FIDL 语言中移除了可选字符串和可选向量。 |
| 作者 | |
| 提交日期（年-月-日） | 2018-09-27 |
| 审核日期（年-月-日） | 2018-10-25 |
拒绝理由
- FTP-016 被拒绝，也就是说，我们暂时保留可选的字符串和向量：
- 我们希望更全面地重新审视可选性，而不是只在某个时间点做出决定。
- 自我们开始考虑此功能的实用性以来，其使用率不断提高，我们应该更好地了解现有的模式以及我们希望鼓励（和阻止）的模式。
- 在绑定级别：
- 改用非可选容器来处理非可选内容。 我们应该让处理非可选内容比处理可选内容更简单，也就是说，如果可选性适合相应网域，您应该明确寻求可选性。
- 关于 C++ 人体工程学：
StringPtr->std::string或fit::optional<std::string>VectorPtr->std::vector<T>或fit::optional<std::vector<T>>
摘要
从 FIDL 语言中移除了可选字符串和可选向量。
设计初衷
注意：在本文档中，我将使用“空字符串”或“空向量”来指代上述情况。由于有线传输的字符串本质上是必须有效的 UTF-8 vector<uint8>，因此它们的有线格式非常相似，并且适用于一种格式的内容通常也适用于另一种格式。
可为 null 的向量和字符串在多种目标语言中难以表示，且不常用。虽然有些使用情形需要区分非字符串和空字符串，但我认为这种情况很少，值得强制要求这些地方明确表示这种情况。 我怀疑，如果我们实现表格，这种情况会更加明显，因为表格可能涵盖了多个不存在的字符串或向量用例。
例如，在 C 和 C++ 中，null vector<T> 表示为零长度和 null 指针，而空 vector 表示为零长度和非 null 指针。根据语言规则，此非 null 指针必须是有效的 T 指针，即使它无法被解引用也是如此。我们目前通过以下方式构造此指针：假设下一个次要对象存储空间位于 T 数组的末尾之后，这在最好的情况下也只是勉强合法，而且无论如何都过于微妙。
我们已修复了因这些规则的细微之处而导致的实现和客户端中的多个 bug。
C++ 表示法在匹配标准 vector 和 string 接口方面也效率低下，因为它使用指向标准容器的指针。同样，Rust 也必须将容器封装在 Option 中。
设计
此提案通过移除可选向量和可选字符串构造来修改 FIDL 语言。
它会影响每个绑定的实现，因为不再需要为这些构造提供表示形式。
实施策略
- 在 FIDL 语言中弃用这些结构。
理想情况下，我们可以从
fidlc发出弃用警告。 - 将
vector?和string?的所有用法迁移到其他表示形式。 在某些情况下，相关接口实际上并不使用可选性。在其他情况下，我们可以手动描述可选性。 - 从 FIDL 以及示例和文档中移除了
vector?和string?。 - 对于每种目标语言：采用此提案现在允许的更好的字符串或矢量实现。
例如，FIDL 向量在 C++ 中可以只是一个
std::vector。
文档和示例
这些构造偶尔会在 go/fidl-tut 等内容中被引用，但绝不是以必需的方式引用。我们应将它们全部更新为非可选版本。
向后兼容性
这会禁止使用该语言中的单个构造。旧版编译器将能够编译未来的代码。
由于我们尚未达到预期中源代码/编译器兼容性窗口较宽的状态，因此成本较低。
性能
我预计效果基本上不会发生变化。
安全
我认为此功能不会对安全性产生任何影响。
测试
我预计，在拉动这些结构的各个用途时，测试将一次进行 1 个 CQ。
我认为不需要为 FIDL 流水线编写任何新测试。 只需要进行修改来移除所有可选字符串或向量。
缺点、替代方案和未知因素
我认为我们不应在生成的代码中放置弃用警告。 这样一来，对这些内容的引用会多得多，而且很难回溯到警告的真正来源。
在某些实际应用场景中，需要区分“不是向量”和“空向量”。不过，uint32 也是如此，我认为我们应该在此提案和表格之后重新考虑可选性。
在先技术和参考资料
虽然其他 RPC 或 IPC 系统肯定也会遇到这类问题，但我并未研究过任何此类系统。 我认为，在这种情况下，设计压力在与其他系统的兼容性、性能需求、目标语言支持等方面差异很大，因此我们不太可能仅通过查看另一个系统是否支持可选字符串来得出有用的结论。